Regex Test Online — Stop Guessing Email Validation
Someone drops a 200-character “perfect email regex” into a PR. Half the QA list fails: [email protected], a .museum TLD, or a corporate address with a subdomain. The other half of false confidence ships to production and rejects paying customers. Email validation is where regex goes from helpful filter to product bug.
What you are actually testing
A regex answers: “Does this string look like our local definition of an email shape?” It does not answer:
- Does the domain exist?
- Does the mailbox accept mail?
- Will the provider bounce it tomorrow?
- Is the user a human?
Those require DNS, SMTP, and confirmation links. Keep the regex humble.
A pragmatic pattern (and its limits)
For many apps, a small pattern is enough to stop "asdf" and "a@b":
// Practical — not RFC-complete
const loose = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;It allows plus tags, long TLDs, and most ASCII addresses. It still fails or over-accepts weird but legal local-parts. That trade-off is fine if signup always sends a verify email.
Paste candidates into a regex tester with a fixture list before you merge:
ok: [email protected]
ok: [email protected]
ok: [email protected]
bad: alice@
bad: @example.com
bad: alice example.comToggle flags deliberately. Multiline mode and global flags change “does the whole string match?” vs “is there a match somewhere?” — a frequent source of “works in the tester, fails in code.”
Stack Overflow traps
| Snippet habit | Failure mode |
|---|---|
{2,3} TLD length | Rejects .info, .museum, new gTLDs |
Disallow + | Breaks Gmail-style filtering |
| “Must start with letter” | Rejects numeric local-parts some orgs use |
| Enormous RFC regex | Unreadable, ReDoS risk, still incomplete |
If the pattern is longer than the validation message, you probably want a library and confirmation mail — not a cleverer expression.
Server vs client
Client regex improves UX (instant red border). Server validation is mandatory. Attackers skip your React form. Mirror the same fixtures in unit tests for both layers so they do not drift.
export function looksLikeEmail(s) {
return typeof s === "string" && /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(s);
}For internationalized addresses, decide explicitly: either normalize to ASCII (punycode) before the check, or accept that your product is ASCII-only and document it.
When to abandon regex entirely
- Marketing preference centers that must accept every legal address → use a maintained validator package + verify send
- Disposable-email blocking → domain lists / services, not character classes
- Login identifier that might be phone OR email → branch first; do not force one mega-pattern
A workflow that stays honest
- Write five valid and five invalid fixtures from real support tickets (scrubbed).
- Test the pattern locally until fixtures pass.
- Ship the loose check + confirmation email.
- Log rejection reasons (format vs bounce vs spam) so you improve the right layer.
Regex is a spell-checker for email strings, not a post office. Use a local tester to stop guessing, keep the pattern short, and let the mailbox — not the parentheses — prove ownership.
Confirmation mail is the real validator
Even a perfect-looking address can bounce, land in spam, or belong to someone who mistyped one character. Product flows that matter (signup, billing, password reset) should treat regex as a typo guard, then send a short-lived confirmation link. Log format failures separately from bounce failures so you improve the right layer. If marketing asks for stricter regex instead of confirm email, push back with support ticket volume from false rejects — that usually ends the debate faster than RFC citations.