Email address regex
Practical, permissive email validator that catches typos without rejecting real addresses.
^[^\s@]+@[^\s@]+\.[^\s@]+$/iWhat it matches
The full RFC 5321/5322 grammar for email is famously complex — quoted local parts, comments inside addresses, IP-literal hostnames, and so on. For almost every form on the web, a permissive pattern that just checks for `something@something.something` with no spaces is the right tradeoff: it catches the typos that matter (missing `@`, missing TLD, stray spaces) without rejecting unusual but valid addresses that the strict grammar allows. This pattern is the same shape recommended by many style guides, including the HTML5 `<input type="email">` spec.
Examples
Matches
dev@tooled.devStandard local@domain.tld form.
first.last+tag@example.co.ukDots, plus-aliasing, and a multi-label TLD are all permitted.
support+regex@example.orgPlus-addressing (Gmail-style filtering) is valid in the local part.
üser@münchen.deUnicode characters work because we used `[^\s@]` — anything except whitespace and `@`.
Does not match
plainNo `@` at all.
no@dotDomain part has no `.` separator.
@no.localLocal part is empty.
spaces in@email.comWhitespace in the local part.
two@@signs.comMultiple `@` characters.
Edge cases & gotchas
- Accepts internationalized email (IDN) domains because we don't restrict to ASCII. If you need ASCII-only, replace `[^\s@]` with `[A-Za-z0-9._%+-]`.
- Accepts addresses with no TLD if the domain has a dot — e.g. `user@host.localnet` matches. Add a length check on the final label if you want a real TLD.
- Accepts addresses with trailing dots (`user@example.com.`). DNS treats these as valid; user-facing forms usually don't. Strip with `.replace(/\.$/, '')` before matching if you care.
- Does NOT catch all RFC violations — that's deliberate. The W3C HTML5 spec uses a similarly permissive pattern.
In your language
// JavaScript
const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/i;
const match = "input".match(re);All 13 languages (including Bash, Perl, Kotlin, Swift) available in the full toolkit Export tab.
Notes for production
- For real validation: combine this pattern with a DNS MX-record lookup or send a verification email. No regex can confirm an inbox is reachable.
- If you absolutely need RFC 5322 compliance, defer to a parser library (`validator.js`, Python `email.utils.parseaddr`). The full grammar is several pages long.
Frequently asked
Why don't you use the 'official' RFC 5322 regex?
Because the official regex is several hundred characters long, accepts addresses no real mail server will deliver to (like quoted local parts with embedded commas), and rejects nothing your users will actually type. The compact permissive pattern catches every typo that matters with 1% of the complexity.
Does this regex prevent injection or XSS?
No. Validation isn't sanitization. Always escape the value when rendering it back into HTML (use your framework's built-in escaping) and parameterize when inserting into SQL.
How do I validate the email actually exists?
Regex can't. The standard playbook is: regex check the format → optional DNS MX-record lookup to confirm the domain accepts mail → send a confirmation email with a tokenized link. Real deliverability checks happen at SMTP time.
Will this match `name@localhost`?
No — the pattern requires a `.` in the domain part. Drop the second `[^\s@]+\.` clause if you actually need to accept dotless hostnames (uncommon outside intranets).