Email regex: validate an email address in JavaScript, PHP and HTML

An email regex does one thing: it checks that a string has the shape of an email address. That is not much, and it is indispensable in every sign-up, contact or order form. Here is the regular expression I have used for years, with its JavaScript, PHP and HTML versions, and above all a detailed look at what it accepts and what it rejects.

The email regex, ready to copy

^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$

Read from left to right:

• ^ and $: the whole string has to be an address, not merely contain one.
• [^<>()[\]\\.,;:\s@"]+: the local part (before the @) is made of permitted characters, with no spaces or reserved punctuation. Groups separated by a dot (prenom.nom) are accepted; a double dot is not.
• |(".+"): the quoted alternative, provided for by the standard, allows "jean dupont"@example.com.
• @, then the domain: either an IP address in square brackets ([192.168.1.1]), or alphanumeric labels separated by dots and ending in a top-level domain of at least two letters.

What the regex checks, and what it does not

The table below is the actual result of test() under Node.js 22 and of preg_match() under PHP 8.5 on sixteen addresses. Both engines return the same verdict.

What no regex can check: that the domain exists, that it accepts mail, and that the mailbox is active. personne@gmail.com has a perfect shape and most likely receives nothing.

JavaScript version

The function takes the address as a parameter, strips the surrounding whitespace and returns true or false. The i flag makes the match case-insensitive.

/**
 * Checks the format of an email address.
 * @param {string} email
 * @returns {boolean}
 */
function validateEmail(email) {
  const emailReg = /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/i;
  return emailReg.test(String(email).trim());
}

console.log(validateEmail('jean.dupont@example.com')); // true
console.log(validateEmail('jean..dupont@example.com')); // false
console.log(validateEmail(' jean@example.com '));      // true, thanks to trim

In a form

The typical use case: block submission and show a message for as long as the address is malformed.

const form = document.querySelector('#inscription');
const champ = document.querySelector('#email');
const erreur = document.querySelector('#email-erreur');

form.addEventListener('submit', (event) => {
  if (!validateEmail(champ.value)) {
    event.preventDefault();
    erreur.textContent = 'Adresse e-mail invalide';
    champ.setAttribute('aria-invalid', 'true');
    champ.focus();
  }
});

The error field is a visible element next to the input, not an alert() box: the user keeps the context and can correct the address straight away.

PHP version

Client-side validation is an aid to data entry, not a security measure. The server has to run the check again: JavaScript can be disabled, and a form can be called directly. The same regex works with preg_match(), give or take the quotes.

/**
 * Checks the format of an email address.
 */
function isValidEmail(string $email): bool
{
    $pattern = '/^(([^<>()[\]\\\\.,;:\s@"]+(\.[^<>()[\]\\\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/i';

    return preg_match($pattern, trim($email)) === 1;
}

var_dump(isValidEmail('jean.dupont@example.com')); // bool(true)
var_dump(isValidEmail('jean@localhost'));          // bool(false)

Note the double escaping of the backslashes in the single-quoted PHP string: \\\\ in the code produces \\ in the pattern, which means “a literal backslash” to the regex engine.

Regex or filter_var?

PHP provides filter_var($email, FILTER_VALIDATE_EMAIL), which follows the standard more closely. Both approaches are valid; they do not rule in quite the same way:

For a public form, filter_var with the Unicode flag is a sound default; the regex remains useful when you want exactly the same rule in JavaScript and in PHP.

HTML version

The browser already knows how to validate an email: type="email" refuses to submit the form if the format is wrong, and displays its own message. The pattern attribute lets you add a stricter rule, this article’s for instance.

<label for="email">Adresse e-mail</label>
<input
  id="email"
  name="email"
  type="email"
  required
  autocomplete="email"
  pattern="(([^<>\(\)\[\]\\.,;:\s@&quot;]+(\.[^<>\(\)\[\]\\.,;:\s@&quot;]+)*)|(&quot;.+&quot;))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))"
  title="Une adresse de la forme prenom.nom@domaine.fr"
>

Four details: pattern is implicitly anchored, so you must not write ^ and $; the quotes in the pattern are written " so as not to close the attribute; browsers compile pattern with the v flag, which requires parentheses and square brackets inside a character class to be escaped (\(\)\[\]), otherwise the pattern is silently ignored; and HTML validation can be bypassed with one line in the console. It improves the user experience; it does not replace the server-side check.

Edge cases worth knowing

• The +: jean+boutique@gmail.com is a valid address that many people use to sort their mail. A regex that rejects it loses sign-ups.
• Long top-level domains: .photography, .paris and .technology exist. That is why the pattern ends in [a-zA-Z]{2,} rather than a closed list of extensions.
• Accents: the local part accepts them; the domain does not in this regex (internationalised domain names are actually written in Punycode, xn--…, before being resolved).
• Surrounding whitespace: copying and pasting from a spreadsheet often adds a trailing space. Call trim() before the test, as both functions above do.
• Case: the domain is case-insensitive; the local part is case-sensitive in theory, but no mainstream provider makes the distinction. Comparing in lower case is the expected behaviour.

Testing the regex before deploying it

A test set beats proofreading. In JavaScript, a loop over known addresses is enough:

const cas = {
  'jean.dupont@example.com': true,
  'jean+news@sub.example.co.uk': true,
  'jean@localhost': false,
  'jean..dupont@example.com': false,
  'jean dupont@example.com': false,
};

for (const [email, attendu] of Object.entries(cas)) {
  const ok = validateEmail(email) === attendu;
  console.log(`${ok ? 'OK ' : 'KO '} ${email}`);
}

To explore a pattern, regex101 colours each group and explains what it captures. Pick the ECMAScript flavour for JavaScript and PCRE2 for PHP: both accept this regex without modification.

Going further: checking that the address exists

Once the shape is right, three further checks cut down on fake addresses, from the cheapest to the most reliable:

1. Reject disposable domains (temporary addresses created to get around a sign-up) using a maintained list.
2. Query the domain’s MX records on the server: a domain with no mail server will never receive a message. In PHP, checkdnsrr($domaine, 'MX') answers in one line.
3. Send a confirmation email with a link to click. It is the only proof that someone reads that mailbox, and it is what every serious service does.

The first two checks are the ones I run on Foliade’s public forms; the third remains the reference as soon as an account is created.

The other validation regexes

Same approach, other formats: validating a date, an IP address, a postcode or a password.