Regex for Email Validation — Pattern and Best Practices
Practical regex patterns for email validation with explanations. Covers basic and robust patterns, RFC 5322 considerations, and when to use regex vs other methods.
Common Patterns
Detailed Explanation
Email Validation with Regex
Email validation is one of the most common regex use cases, but it is also one of the most misunderstood. Here is a practical approach.
Basic Pattern
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
This pattern covers the vast majority of real-world email addresses:
| Token | Matches |
|---|---|
[a-zA-Z0-9._%+-]+ |
Local part (before @) |
@ |
Literal @ symbol |
[a-zA-Z0-9.-]+ |
Domain name |
\.[a-zA-Z]{2,} |
Top-level domain (.com, .org, etc.) |
What This Pattern Handles
- Standard emails:
user@example.com - Dots and hyphens:
first.last@sub-domain.example.com - Plus addressing:
user+tag@gmail.com - New TLDs:
user@example.technology
What This Pattern Misses
The full RFC 5322 email specification is extremely complex and practically impossible to capture in a single regex. Edge cases include:
- Quoted local parts:
"user name"@example.com - IP address domains:
user@[192.168.1.1] - International domain names (IDN)
Best Practices
- Use a simple regex for client-side validation — catch obvious typos
- Send a confirmation email — the only true validation
- Do not reject valid addresses — overly strict patterns frustrate users
- Consider using the HTML5 input type="email" as a first layer of validation
Use Case
You are building a form that needs client-side email validation to catch typos before submission, or you are extracting email addresses from a block of text using regex search.