Why You Should Not Validate Email With a Giant Regex

Search for an email validation regex and you will find monsters: patterns hundreds or thousands of characters long, presented as the correct, RFC-compliant answer. Reaching for one of these is almost always a mistake. It does not do what you think, it cannot do what you actually need, and it can even open a security hole. Here is why, and the small, boring approach that works instead. You can try any of these patterns in the Regex Tester as you read.

The RFC regex is a trap

The grammar for a valid email address in RFC 5322 is genuinely intricate. A regex that honours all of it runs to thousands of characters, and you cannot read, maintain, or reason about it. Worse, a pattern that complicated, fed hostile input, is a candidate for catastrophic backtracking, turning your validation step into a denial-of-service waiting to happen. You would be importing a security risk to solve a form-field problem.

It rejects real people and accepts dead addresses

Even a careful pattern gets both directions wrong. It rejects perfectly valid addresses, plus-addressing, new top-level domains, and internationalised addresses with non-ASCII characters, which means turning away real users. And it accepts addresses that are well-formed but undeliverable: nothing in the syntax tells you whether the mailbox exists. A string can pass the strictest regex and still bounce on the first send.

What the goal really is

Step back and ask what validation on a form is for. The honest goal is small: catch obvious typos before the user submits, reject empty or clearly broken input, and give quick feedback. You are not trying to prove the address works. So the format check should be deliberately loose, just enough to flag the mistake of leaving out the @ or the domain.

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

"some characters, an @, some characters, a dot, some characters,
 and no spaces anywhere"

It accepts a.b+tag@sub.example.museum and rejects "bob" or
"bob@", which is exactly the job. It cannot backtrack badly,
and it turns nobody real away.

This is essentially the spirit of the pattern browsers use for an input of type email: intentionally permissive, fast, and good enough to catch fumbles. If the built-in HTML email input meets your needs, prefer it and skip the regex entirely.

The only real validation is sending mail

If you truly need to know an address is good, there is exactly one reliable test: send a message with a confirmation link and have the recipient click it. That proves the mailbox exists and the person can read it, which is the actual property you wanted all along. A loose format check in the form plus a confirmation email beats any regex, however clever.

• In the form: a simple, permissive pattern (or the native email input) to catch typos.
• On the server: a vetted email-parsing library if you need more rigour, never a hand-rolled mega-regex.
• To confirm it works: a verification email. This is the only step that proves deliverability.

Try the sane pattern

Paste the loose pattern above into the Regex Tester and throw a mix of good and bad addresses at it; you will see it does the real job without drama, all in your browser. For a thorough and refreshingly honest treatment of the whole problem, the page on matching email addresses at regular-expressions.info is the reference to read.