Email Validation
Email Regex Cheatsheet
Compare practical email regex patterns, test cases and validation limits before using a pattern in forms, APIs or imports. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Start permissive | Reject obvious mistakes while keeping valid real-world addresses such as plus tags and subdomains. |
| Test edge cases | Check empty strings, missing domains, double at signs, whitespace and long addresses. |
| Separate syntax from delivery | A regex can check shape, but it cannot prove that a mailbox exists. |
| Mirror server logic | Client and server validation should disagree as little as possible. |
Starter snippet
Basic pattern: /^[^\s@]+@[^\s@]+\.[^\s@]+$/
Use for: quick client hints
Do not use for: final deliverability proofReview checks
- Accept plus addressing such as name+tag@example.com.
- Reject spaces and missing domain dots.
- Keep the pattern readable enough for code review.
- Document whether internationalized domains are supported.
Common mistakes
- Using a pattern so strict that valid addresses are rejected.
- Treating regex success as proof of deliverability.
- Running a catastrophic backtracking pattern on untrusted bulk input.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Regex Email Validator, Email Regex Javascript Guide, Email Regex Test Cases.