Email Regex Pattern
The pattern above matches the vast majority of real-world email addresses. It requires a non-empty local part using alphanumerics and the characters ._%+-, then an @, then a domain with at least one dot, then a TLD of two or more letters. Lines that match: user@example.com, alice.chen@company.co.uk, bob+tag@gmail.com. Lines that do not match: invalid@, @missing-local.com, no-at-sign.com, user@.com.
Pattern Breakdown
| Segment | Pattern | What it matches |
|---|---|---|
| Start anchor | ^ | Beginning of each line (with m flag) |
| Local part | [a-zA-Z0-9._%+\-]+ | Letters, digits, and ._%+- — one or more |
| At sign | @ | Literal @ |
| Domain labels | [a-zA-Z0-9.\-]+ | Domain name, allowing dots and hyphens |
| Dot before TLD | \. | Literal dot |
| TLD | [a-zA-Z]{2,} | Two or more letters (covers .io, .museum, .co.uk second label) |
| End anchor | $ | End of each line (with m flag) |
Common Mistakes in Email Regex
Not allowing + in the local part is the most frequent problem. Gmail and many other providers route user+tag@gmail.com to the same inbox as user@gmail.com, and plenty of users rely on this for filtering. A pattern like [a-zA-Z0-9._%-]+ quietly rejects these addresses.
Not allowing multi-level TLDs is the second most common mistake. A pattern ending in \.[a-zA-Z]{2,3} rejects alice@company.co.uk because it sees .co as the TLD, which is only two characters. The pattern on this page avoids this by matching everything after the last dot separately.
Not anchoring the pattern with ^ and $ means a string like this is not@an email but it contains one will match the embedded fragment. When validating, always anchor to the full string or line.
The HTML5 Email Pattern
Browsers apply their own pattern to <input type="email">. The actual pattern used by the HTML5 spec is:
/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/This allows characters like !#$%&'* in the local part, which are valid per RFC 5321 but almost never seen in practice. Using type="email" gives you this validation for free in supporting browsers.
What Regex Cannot Tell You
A regex can confirm the address looks like an email. It cannot tell you whether the domain has working MX records, whether the mailbox exists, or whether the user controls the address. The standard approach for any flow that depends on a real email address is:
- Apply a basic format check (regex or
type="email") to catch obvious typos. - Send a confirmation email with a time-limited token.
- Only treat the address as verified once the user clicks the link.
This covers the cases that regex misses entirely, including mistyped domains (gmial.com) and addresses that look valid but belong to someone else.
Practical Recommendation
For most applications, use the pattern on this page (or the HTML5 type="email") to catch obvious input errors, then verify ownership with a confirmation email. Reach for a validation library only if you need to handle international addresses, parse raw email headers, or enforce stricter rules than the default pattern provides.
If you work with URLs as part of the same form, the URL Encoder can help you safely encode query string parameters that include email addresses.