Email Validator

Check whether an email address is well-formed — one address, or a whole list, one per line.

Email Address

Valid

Looks like a valid email address.

What makes an email valid?

A valid address has a local part, an @, and a domain with at least one dot — e.g. [email protected]. The official RFC 5322 grammar is famously complex, so this tool applies a strict but practical pattern plus length and structural checks (single @, no leading/trailing or doubled dots). Switch to Bulk mode to check a whole list one address per line and copy just the valid ones, and it flags likely domain typos (e.g. gmail.con → gmail.com). It verifies syntax only — whether the mailbox actually exists requires sending mail. Validation runs entirely in your browser.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Catching an obvious typo in an address before a signup flow bounces.
Checking whether a form's own validation is stricter than the specification allows.
Validating a list of addresses from a spreadsheet before an import.
Distinguishing a malformed address from a well-formed one that simply does not exist.
Confirming that an unusual but legal address is being rejected by your code rather than by the standard.

Frequently Asked Questions

Why not implement RFC 5322 exactly?: Because the full grammar allows quoted local parts, comments in parentheses, IP-literal domains and folding whitespace — the canonical regular expression for it runs to several thousand characters and still accepts addresses no mail server would deliver to. A strict practical check is more useful.
Can validation tell me an address exists?: No. Syntax is all a client can check. Whether a mailbox exists needs the receiving server, and most now refuse to say — catch-all domains accept everything and SMTP callout verification is widely blocked as an abuse signal.
Are plus addresses valid?: Yes. `[email protected]` is entirely legal and Gmail, Fastmail and others use it for filtering. Rejecting it is a bug, and a common one — as is rejecting apostrophes, which appear in plenty of real Irish and Italian surnames.
Is the local part case-sensitive?: Technically yes: the standard leaves case handling to the receiving server, so `User@` and `user@` may differ. In practice every major provider treats them the same. Domains are always case-insensitive. Store what the user typed, compare case-insensitively.
What is the only reliable check?: Sending a confirmation email. A typo like `gmial.com` is syntactically perfect, and a suggestion for a near-miss domain is worth offering — but the address is only proven when a message to it is received and acted upon.
What is the only reliable validation?: Sending a message and having the recipient act on it. Syntax checks catch typos in structure, and MX lookups confirm the domain accepts mail, but neither proves the mailbox exists or that its owner gave you the address.

Common errors and gotchas

Reading well-formed as deliverable. Only sending a message can tell you the mailbox exists.
Rejecting a plus-addressed local part, which is legal and widely used for filtering.
Assuming a two-or-three letter top-level domain. Long ones are common and a length rule breaks them.
Rejecting a quoted local part or unusual characters that the specification permits, which loses real users.
Lowercasing the local part before comparison. It is technically case-sensitive even though most providers ignore that.