Email validator

What is an email validator?

An email validator answers whether a string is a well-formed email address. Sign-up forms use one to catch typos before they cost a password reset, mailing lists use one to keep bounces down, and developers reach for one when a regular expression copied off the internet has started rejecting a customer whose address is perfectly legal.

The catch is that there is no single answer, and the specifications say so themselves. The WHATWG HTML standard defines what an <input type=email> field accepts, and describes its own definition, in those exact words, as “a willful violation of RFC 5322” — the internet standard for message formats. It gives three reasons: RFC 5322 is too strict before the @, too vague after it, and too lax in allowing comments, whitespace and quoted strings that would baffle most users.

All three of those complaints hold up when you check them, and the consequence is the thing this page exists to show: neither standard is a subset of the other. Each accepts addresses the other rejects. So this tool reports both verdicts side by side, and names the rule that made the call.

How to use it

1. Paste your addresses, one per line. A single address works and so does a list of thousands. Blank lines are skipped rather than counted as failures, and surrounding spaces are trimmed, so pasting a column out of a spreadsheet does what you expect.
2. Read the two badges on each row. One is the HTML form rule, the one that decides whether a browser will let a visitor submit the field. The other is RFC 5322, the one a mail library implements. When they disagree the row is flagged, because that is the case worth knowing about.
3. Read the reason underneath. Whichever standard rejected the address, the line beneath says which rule did it — a dot in the wrong place, a quoted local part, a bracketed comment, a hyphen at the edge of a domain label. A verdict without a reason is not much use when you are trying to decide whether to fix the address or fix the validator.

Where the two standards part company

Three ordinary-looking addresses are valid under the HTML rule and invalid under RFC 5322, and all three are about dots. RFC 5322 builds the part before the @ out of a “dot-atom” — pieces of text joined by single dots — so a doubled dot, a leading dot or a trailing dot breaks the grammar. The HTML pattern simply allows dots anywhere in that run of characters. So john..doe@example.com passes a browser form and fails a strict parser.

Rather more addresses go the other way. RFC 5322 lets the part before the @ be a quoted string, so "john..doe"@example.com is legal — the quotes make the dots data rather than structure. It allows bracketed comments almost anywhere, so john.doe(comment)@example.com parses fine. It lets the domain be a literal address in square brackets, covering both user@[192.168.0.1] and the IPv6 form. And its domain grammar has no label rules whatsoever, which is what the HTML standard means by “too vague”: user@-example.com and a domain label 64 characters long are both syntactically fine by RFC 5322 and both rejected by the browser.

The practical reading is that the HTML rule is a deliberate compromise, not a mistake. It is narrower where the RFC is permissive about things nobody types, and wider where the RFC is fussy about things people do type. If you are validating a form field, matching the browser is usually the right call. If you are writing a mail parser, it is not.

Honest limits

Neither column tells you whether mail would actually arrive. That is a third question entirely — does the domain exist, does it have a mail server, does the mailbox exist, will it accept a message — and it needs DNS lookups and an SMTP conversation. A page running in your browser can do none of that, so this tool does not pretend to. Anything that claims to verify deliverability without sending a message is either guessing from a list of known domains or doing the work on a server you are handing your list to.

The lengths are worth knowing and are stranger than they look. RFC 5321 caps the part before the @ at 64 octets and the domain at 255. The 254-character total that every validation library uses appears in the body of no RFC at all: it comes from a verified erratum against RFC 3696, which derives it from the 256-octet limit on a forward-path, minus the two angle brackets that a path is required to have around the address. An earlier erratum said 256 and was corrected by exactly those two characters. Follow the arithmetic one step further and something odd falls out — 64 plus one plus 255 is 320, comfortably over 254, so the two component maxima can never both be reached in a real address.

Lengths here are counted in octets rather than characters, because that is what the RFC says. For an ordinary ASCII address the two are the same number, but an accented character takes two bytes and an emoji takes four, so a short-looking address can be longer on the wire than it appears on screen.

Both standards implemented here are ASCII-only, and that is a real limitation rather than an oversight. Internationalised addresses — non-ASCII before or after the @ — are defined by later specifications, and support for them is uneven enough across mail software that treating them as simply valid would be its own kind of lie. When one turns up, the tool says which character caused it rather than silently failing.

One thing this tool deliberately does not do is guess at typos. Suggesting that gmial.com should have been gmail.com requires a list of popular providers, and a list like that is a snapshot that quietly goes stale and starts correcting people who genuinely use a smaller domain.

Why is it free?

Because it costs nothing to run. Both standards are implemented in your browser, so the addresses you paste never leave your machine — which matters more here than on most pages, since an email list is exactly the kind of thing you should not be uploading to a stranger's server to have it checked.

There is no account, no cap on how many addresses you can check at once, and nothing withheld behind a paid tier. The implementation is checked against a real RFC 5322 parser rather than against expectations written by hand, and against the HTML standard's own published regular expression, so the verdicts on this page are ones it can defend.