Why Most Email Regex Patterns Are Wrong (And What to Use Instead)
I have watched the same email regex bug ship in three different companies. The pattern looked responsible, something like ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$, and it quietly rejected real customers. A woman named O'Brien could not register because of the apostrophe. A German user with an umlaut in his domain was told his address was invalid. A plus-addressed Gmail user, the kind who uses name+shopping@gmail.com to track who sells their data, got bounced by a signup form. Each time, the fix was the same: stop trying to be clever, and understand what an email regex can and cannot do.
The two failure modes
Email regexes fail in two opposite directions. The strict ones reject valid addresses. The loose ones accept garbage. Most hand written patterns are strict in the wrong places and loose in the wrong places simultaneously, which is quite an achievement.
Too strict: patterns that whitelist specific TLDs, or forbid plus signs, or require the TLD to be 2 to 4 letters. That last one was defensible in 2003. Today there are TLDs like .technology and .international, and country codes are still 2 letters, so {2,4} rejects real domains on both ends. Apostrophes are valid in the local part. So are many characters people never expect. If your pattern does not accept o'brien@example.com and user+tag@example.technology, it is wrong.
Too loose: the classic ^.+@.+\..+$ accepts a@b.c and @@@-shaped nonsense. Worse, patterns without anchors match substrings, so a "validator" built on an unanchored pattern will happily accept not an email user@example.com definitely not because it found an email shaped thing inside.
The pragmatic pattern most validators actually use
Here is what experienced teams converge on, and what JSON Schema's email format check looks like in practice:
^[^\s@]+@[^\s@]+\.[^\s@]+$
Read it as: something that is not whitespace or @, then @, then something that is not whitespace or @, then a dot, then something that is not whitespace or @. It is deliberately permissive. It will not reject O'Brien, umlauts, plus addressing, or new TLDs. It catches the actual typos users make: missing @, missing domain, spaces pasted from a spreadsheet.
This is a willful violation of RFC 5322, and that is the point. The HTML5 spec's email validation does exactly this kind of deliberate simplification, because the RFC grammar allows comments, whitespace folding, and quoted strings in ways no real signup form should accept. Full RFC compliance in a regex is thousands of characters long and still cannot tell you whether the inbox exists.
What a regex cannot do (and what to do instead)
A regex answers one question: does this string have the shape of an email address? It cannot answer the question you actually care about: can I reach this person? Only the mail server knows that.
The correct validation stack, in order:
- Format hint: the permissive pattern above, run client side for instant feedback. Catch typos, not people.
- Normalization: lowercase the domain part. Do not lowercase the whole address aggressively; the local part is technically case sensitive, though in practice every major provider treats it as case insensitive.
- Confirmation: send a verification email with a link or code. This is the real validation. Everything before it is UX.
- Optional: a blocklist of disposable domains if abuse is a real problem for you, and length checks (254 characters total, 64 for the local part).
If you are validating emails server side for security purposes, use a mature RFC parsing library, not a hand rolled pattern. The edge cases that matter there, header injection via newlines, quoted local parts, address literals, are exactly the ones a regex gets wrong.
My rule of thumb
Be liberal in what your pattern accepts and strict in what your confirmation flow requires. Every false rejection is a customer you turned away at the door. Every false acceptance costs you one bounced verification email, which your system already handles. The asymmetry is enormous, and it points in one direction: when in doubt, accept the shape and verify by sending.