Every developer has met the giant email regex: a pattern so long it fills the screen, copied from a forum post, promising to validate email addresses perfectly. It feels safe to use. It is not. Strict email patterns reject real addresses that people actually use, and they do it silently, at the exact moment a user is trying to sign up or check out. The pragmatic alternative is smaller, more honest, and easier to explain. Regex Tester lets you try both kinds of pattern against a list of sample addresses and see the rejections happen, rather than taking anyone's word for it.
The root of the problem is the email specification itself. The formal rules for what counts as a valid address are far broader than everyday experience suggests. Addresses can contain plus signs, dots, quoted strings, and characters most developers would never expect. A pattern that tries to encode every rule becomes enormous, and a pattern that encodes only the familiar cases — letters, dots, an at sign, a domain — rejects everything else. There is no middle-sized pattern that gets this exactly right, because the specification and common usage pull in opposite directions.
The addresses strict patterns reject
Consider a set of fictional addresses, invented for this example, all of which belong to plausible real-world styles: sara+shop@example.com, first.last@example.org, team-mailbox@example.com, and user@sub.example.com. A naive pattern like ^[a-z]+@[a-z]+\.[a-z]+$ rejects the first outright, because it has no rule for a plus sign, and rejects the fourth because it allows only one dot in the domain. The plus-sign case matters: many people use plus addressing to sort incoming mail, and rejecting it loses a genuine user for no benefit.
Longer patterns fix some of these cases and break others. A pattern that allows plus signs but not quoted local parts, or that limits the top-level domain to a short list, will still reject someone. Domain rules have changed over the years, new endings appear regularly, and a hard-coded list goes stale. A pattern that caps the local part at an arbitrary length or forbids hyphens in a domain will reject addresses that mail servers accept without complaint. Each restriction feels reasonable in isolation and is wrong in combination, because the pattern's author is guessing at rules that belong to mail servers, not to forms.
Worked example: testing a pragmatic pattern
A pragmatic pattern does not try to prove an address is deliverable. It checks only that the input has the basic shape of an address — something, an at sign, something, a dot, something — and leaves real verification to the step that can actually do it: sending a confirmation message. Here is a simple version to test:
^[^\s@]+@[^\s@]+\.[^\s@]+$In plain language: one or more characters that are not spaces or at signs, then an at sign, then one or more such characters, then a dot, then one or more such characters. Test it against the fictional addresses above, plus obvious failures like not-an-address, sara@, and sara@example. The good addresses pass, the failures fail, and the pattern is short enough to read and explain to a colleague.
Now test the same list against a stricter pattern, for instance one that forbids plus signs or limits the domain to two or three letters after the final dot. The plus-addressed sample fails, and an address with a longer domain ending fails too. The highlighted matches in the tester make the reason visible: the match stops at the forbidden character, or fails entirely. This comparison is the whole argument in miniature. The strict pattern does not catch more fake addresses in any meaningful way — a nonsense string like x@y.zz passes most strict patterns anyway — but it does reject real people.
What to do instead of perfect validation
The honest workflow has three layers, and regex is only the first. First, use a simple shape check like the pattern above to catch typos and empty fields: missing at signs, missing dots, spaces accidentally pasted in. Second, if the address matters, send a confirmation message with a link or code. Only the mailbox owner can complete that step, which is a far stronger check than any pattern. Third, normalise gently: trim surrounding spaces and treat the domain part case-insensitively, since mail domains do not distinguish upper from lower case.
There are also things a pattern should never do. It should not reject an address because the domain is unfamiliar, because unfamiliar domains are created constantly. It should not demand a particular domain ending, and it should not try to check whether the domain exists — that is a network lookup, not a pattern match, and it belongs elsewhere in the system. A form that tells a user "invalid email" when their address is perfectly good is worse than a form that accepts a slightly odd address, because the first loses a real person and the second merely needs a confirmation step.
Honest limitations
No regex can confirm that an address belongs to the person typing it, or that the mailbox exists. A pattern can only judge shape, and even the best shape check passes nonsense like a@b.cd. Regex also cannot keep up with specification edge cases: quoted local parts, international characters, and comments in addresses are all legal in theory and vanishingly rare in practice, and a pattern that handles them is unreadable. The tester itself uses JavaScript regex, so a pattern tuned here may need adjustment in another language, particularly around Unicode handling. For the performance side of pattern design, including the timeouts that protect against slow patterns, see the regex safety guide.
FAQs
Can a regex fully validate an email address?
No. The formal rules are extremely broad, and real-world usage is narrower but still varied. A regex can check basic shape; only sending a confirmation message can verify that an address is real and belongs to the person who entered it.
Why does my email pattern reject addresses with a plus sign?
Because the pattern's character class for the local part does not include +. Plus addressing is a legitimate, widely used feature. A pragmatic pattern allows any non-space, non-at characters in that position instead of listing permitted ones.
Is a short email pattern less secure?
Not in any meaningful way. A strict pattern still accepts nonsense addresses like x@y.zz, so it adds no real security. The security comes from confirmation: only the mailbox owner can click a link or enter a code sent to that address.
Should I check the domain part against a list of endings?
No. New domain endings appear regularly, and a hard-coded list goes stale and starts rejecting real addresses. Check only that a dot and something after it are present, and let confirmation handle the rest.
If your validation logic sits inside structured data, JSON Studio can check the surrounding format, and Text Compare can show exactly what changed when you relax a pattern in a form's code.
human review pending client designation