Email Validator
Validate email addresses with our free online tool
Enter a complete email address to check its validity
• Username can contain letters, numbers, dots, underscores, percent, plus, or minus
• Must have the format [email protected]
• Domain must contain letters, numbers, dots, and hyphens
• Must have a valid top-level domain (TLD)
• Cannot contain spaces or certain special characters
How to use Email Validator
- 1
Enter an email address
Type or paste a complete email address such as [email protected] into the input field.
- 2
Click Validate Email
Press Validate Email to check the address against standard email format rules.
- 3
Review the validation details
See whether the address is valid and inspect each check: the @ symbol, username, domain format, top-level domain, and overall format.
- 4
Copy or clear
Use Copy to save a confirmed address, or Clear to test another one.
Email Validation: What It Can and Cannot Tell You
Two very different questions
When people say they want to validate an email address, they usually mean one of two distinct things, and conflating them causes most of the confusion in this area. The first question is syntactic: is this string shaped like an email address, with a local part, an at sign, and a domain ending in a recognizable top-level domain? The second is about deliverability: does this mailbox actually exist and can it receive mail? These are completely separate problems, and passing the first says almost nothing about the second.
This tool answers the first question. It checks the format of an address against standard structural rules and reports which parts pass: the at symbol, the username portion, the domain, the top-level domain, and the overall shape. A green result means the address is well-formed, not that anyone is on the other end.
Syntax validation versus deliverability
Deliverability verification goes far beyond format. It typically involves a DNS lookup to confirm the domain has MX (mail exchange) records, meaning the domain is actually configured to receive email, followed in some cases by an SMTP probe that connects to the mail server and asks whether the specific mailbox exists. These checks require network access to external mail servers and cannot be done from a string alone in the browser. Even then they are imperfect, because many mail servers deliberately accept any address to thwart exactly this kind of probing.
So a layered picture emerges. Syntax validation, which this tool performs locally, is instant and private and catches typos and obviously malformed input. Deliverability checks, which require a dedicated verification service, catch dead domains and some nonexistent mailboxes but still cannot guarantee a real human will read the mail.
Why perfect regex validation is effectively impossible
The formal grammar for an email address, defined in the standard known as RFC 5322, is famously sprawling. It permits quoted local parts containing spaces and special characters, comments in parentheses, and a range of constructs almost nobody actually uses. A regular expression that accepts every technically valid address and rejects every invalid one is so enormous and unreadable that it is a running joke among developers, and even then it cannot verify that the domain exists. Practical validators, including this one, deliberately implement a sensible, common-sense subset rather than the full grammar.
The takeaway is that any reasonable email validator makes a tradeoff. It accepts the vast majority of real-world addresses while rejecting clear garbage, and it consciously does not try to honor every exotic corner of the specification, because doing so would reject obvious typos less reliably and still provide no proof of deliverability. Format validation is a filter, not a guarantee.
Valid addresses that naive checks wrongly reject
Overly strict validators routinely reject perfectly legitimate addresses, which is worse than being slightly lenient because it turns away real users. Plus-addressing is a prime example: an address like [email protected] is valid and widely used for filtering, yet many home-grown checks reject the plus sign. Subdomains in the domain part, as in [email protected], are valid but trip up patterns that assume a single dot. The explosion of new top-level domains, from short ones to long brand and generic extensions, breaks old rules that hard-coded a two-to-four-letter TLD.
Internationalized addresses push further still. Modern standards allow non-ASCII characters in both the local part and the domain, so addresses using accented letters or entirely non-Latin scripts can be legitimate. A validator that assumes ASCII-only will wrongly reject these. The lesson for anyone building a signup form is to lean toward acceptance: rejecting a real customer's valid address is a costly false negative.
False positives: well-formed but wrong
The opposite failure is accepting an address that is syntactically perfect but useless. A typo'd domain like [email protected] passes every format check yet goes nowhere, and a deliberately fake but well-formed entry such as [email protected] sails through too. Disposable and throwaway addresses are also valid in form, as are addresses for mailboxes that were deactivated years ago. None of these can be caught by syntax alone, which is exactly why a format check can never confirm that mail will arrive.
Some of these can be mitigated with extra steps a format checker does not perform, such as flagging common domain typos or comparing the domain against a list of known disposable providers. But the fundamental limit stands: looking right and being real are different properties, and only one of them is visible in the text of the address.
The only definitive test is a confirmation email
Despite every validation technique, there is exactly one way to be certain an address both exists and belongs to the person who entered it: send a message to it with a unique confirmation link and require them to click it. This is the double opt-in pattern used by virtually every reputable mailing list and account system. It proves deliverability, proves ownership, and protects you from typos and from someone signing up another person's address, all at once. Format and deliverability checks are useful pre-filters, but confirmation is the ground truth.
A sound real-world flow therefore stacks the methods: validate format on the client for instant feedback and to catch typos as the user types, optionally run a deliverability check on the server to weed out dead domains before you waste a send, and then always send a confirmation email as the final, authoritative step. Each layer removes a different class of bad address.
Using client-side validation well
Client-side format validation, which is what this tool does and what a signup form should do in the browser, shines as immediate user feedback. Catching a missing at sign or an obvious typo the instant someone finishes typing is far better than letting them submit and waiting for a bounce. Because it runs locally, it is instant and private, with the address never leaving the page. The key is to use it as a helpful nudge, not a gatekeeper, keeping the rules permissive enough that real but unusual addresses still pass.
Treat client-side validation as the first and friendliest layer of defense rather than the whole strategy. Pair the instant format check here with a server-side confirmation step for anything that matters, and you get the best of both: a smooth experience that catches mistakes early, backed by a process that actually proves the address works.
Frequently asked questions
What exactly does this tool check?
Does a valid result mean the email can receive mail?
What characters are allowed in a valid address?
Why is my address marked invalid?
Is my email address kept private?
Related tools
Keep going with these handy tools