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: