Email Validator (syntax + common typo detection)
Type an email to check whether the syntax is valid and to spot domain typos like 'gmial.com' → 'gmail.com'. Breaks down local-part, domain, TLD, and warns on RFC limit violations.
- Local part
- user
- Domain
- example.com
- TLD
- com
- Plus tag (+)
- —
How it works
What this validator does (and what it can't)
Email syntax validation checks whether 'name@domain.tld' follows the structural rules in RFC 5322. We use a pragmatic regex that catches almost all real-world typos while staying flexible enough for legitimate addresses with plus tags, dots, and unusual TLDs.
What this can NOT do: confirm the address actually receives mail. That requires sending a real email or doing an SMTP check, both of which require server-side code and risk false positives (catch-all domains, greylisting). Syntax validation catches typos cheaply; deliverability checks need a different approach.
Common typo detection
We watch for typos in the major free email providers — 'gmial.com' instead of 'gmail.com', 'yaho.com' instead of 'yahoo.com', etc. About 95% of email signup typos are domain typos in these few providers. Catching them client-side saves you a bounced welcome email and an uncomfortable 'please check your address' follow-up.
If you're building a signup form, run this same logic before submitting. Show a 'Did you mean…?' suggestion and let the user accept or override. Mature signup flows do this routinely; it noticeably improves email deliverability.
Local part rules
Plus tag ('user+filter@gmail.com'): widely supported by major providers. Use to create unique addresses for different sign-ups while keeping a single inbox.
Dots ('user.name@gmail.com'): treated as the same address by Gmail (dots are ignored), but other providers may treat them as different addresses. Don't rely on dot-equivalence outside Gmail.
Length: RFC 5321 limits local part to 64 chars and the full address to 254 chars. We warn when these are exceeded — most servers reject longer addresses.
Case sensitivity: per RFC, local part is case-sensitive but most providers treat it as case-insensitive. Domain is always case-insensitive.
Frequently asked questions
›Does this confirm the email exists?
No — only syntax. Confirming an inbox exists requires a server-side SMTP check or sending a verification email. This tool catches typos cheaply.
›Why did it accept 'a@b.co'?
Because that is technically valid syntax. The TLD '.co' is real (Colombia). Validation by syntax can't filter real-but-rare TLDs.
›What about emails with unicode (e.g., 用户@例え.jp)?
Internationalized email addresses are valid per RFC 6531 but the regex used here doesn't accept them. Most form backends still don't either. For unicode-friendly validation, use a dedicated library.
›What's a plus tag?
Anything between + and @ is treated by Gmail and many providers as part of routing. user+toolify@gmail.com goes to user@gmail.com but you can filter by the +toolify suffix.
›Why does Gmail ignore dots?
Historical Gmail policy. user.name@gmail.com and username@gmail.com deliver to the same inbox. Other providers (Yahoo, Outlook) treat them as distinct.
›What's the longest valid email?
254 characters total per RFC 5321. Local part ≤ 64. Most servers reject anything longer.
›Does the data leave my browser?
No. Validation runs locally; nothing is sent to any server.
›Can I bulk-validate?
Not in this tool — paste one address at a time. For lists, use a script or dedicated bulk-validation service (with consent for those whose addresses you check).
Related tools
Last updated: