JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
Email Syntax Validator
Check address syntax against RFC 5322 and spot common typos.
What it does. This checks whether an address is <em>syntactically</em> valid and flags likely typos. It cannot check whether the mailbox exists — that requires an SMTP conversation with the receiving server, which a browser cannot open. Any tool claiming to verify deliverability from a web page is using a third-party service in the background.
Runs in your browserNothing uploadsNo signupWorks offline
How to use Email Syntax Validator
- Paste one address or a list, one per line.
- Read the syntax result and any typo or disposable-domain warnings.
- Export the cleaned list.
What syntax validation can and cannot tell you
Syntax validation catches the large category of addresses that cannot possibly work: missing @, spaces, invalid characters, a domain with no dot, a trailing period.
It cannot tell you whether anyone reads that mailbox. definitely.not.real@gmail.com is perfectly valid syntax and almost certainly undeliverable.
The honest boundary matters because the gap is where marketing lists rot. A syntactically clean list can still be 30% dead. Only sending — or a provider that performs SMTP verification — reveals that.
The rules are stranger than people expect
- Quoted local parts are legal:
"john doe"@example.comis a valid address. - Plus addressing is standard.
you+shop@gmail.comdelivers to you@gmail.com, and rejecting it is a bug. - The local part is case-sensitive by specification, though almost every provider treats it as insensitive.
- IP-literal domains are valid:
user@[192.168.1.1]. - New TLDs are long. Validators capping the TLD at four characters reject .photography and .international.
The practical lesson is to validate loosely. An over-strict regex rejects real customers, and the cost of that is far higher than the cost of accepting an address that later bounces.
Typos worth catching
A small number of domain misspellings account for a large share of failed signups, and they are worth correcting at the point of entry rather than discovering at send time.
gmial.com, gmai.com, gmail.co, hotmial.com, yahooo.com and outlok.com are the recurring ones.
Suggesting a correction is better than rejecting the address. The person may genuinely be at an unusual domain, so offer "did you mean gmail.com?" rather than refusing to accept the input.
Frequently asked questions
Can you tell me if this email address really exists?
No, and neither can any purely browser-based tool. Confirming a mailbox requires an SMTP conversation with the receiving mail server, which a browser cannot open. Anything claiming otherwise is calling a third-party service.
Is user+tag@gmail.com valid?
Yes. Plus addressing is standard and delivers to the base mailbox. Forms that reject it are broken, and it is one of the most common validation bugs on signup pages.
Why does your validator accept odd-looking addresses?
Because RFC 5322 permits more than people expect — quoted local parts, IP-literal domains, long TLDs. Over-strict validation rejects real customers, which costs more than accepting an address that later bounces.
Is my list uploaded anywhere?
No. Validation runs in your browser. That matters here more than usual, since an email list is personal data under GDPR and uploading one to a third party is a transfer that needs a lawful basis.
Should I block disposable email domains?
Rarely. Blocking them also blocks privacy-conscious users, and the lists are always out of date. If abuse is the concern, rate limiting and verification emails address it better.