Email Address Validation
Validate email addresses with a standard pattern covering most common formats.
What Is This?
This regex pattern validates standard email address formats. It checks for the basic structure: a local part (letters, dots, hyphens, underscores), the @ symbol, a domain name (with optional subdomains), and a top-level domain of at least 2 characters.
How to Use This Pattern
Pattern
^[\w.-]+@[\w.-]+\.\w{2,}$
^[\w.-]+@[\w.-]+\.\w{2,}$Usage
The pattern allows dots, hyphens, and underscores before the @ sign. The domain can have multiple levels (e.g., mail.company.co.uk). The TLD must be at least 2 characters. This is a practical validation pattern — RFC 5322 compliant full validation would be significantly longer.
Flags
Use the i flag for case-insensitive matching.
Examples
Matches: user@example.com, john.doe@company.co.uk, user_name@domain.org. Non-matches: user@com, @domain.com, user@.com
Matches: user+tag@example.com, user@sub.domain.com, first.last@company.io. Non-matches: user@domain, user@domain.c, user@domain.com
Related Entries
More from this reference:
URL Pattern
Match HTTP and HTTPS URLs with optional port, path, query string, and fragment.
Phone Number (US/International)
Match US and international phone numbers with optional country code and separators.
Date (YYYY-MM-DD)
Match dates in ISO 8601 YYYY-MM-DD format with basic month and day validation.
Credit Card Number (Generic)
Match generic credit card numbers in grouped or continuous 16-digit format.
Frequently Asked Questions
Is this pattern RFC 5322 compliant?
No. RFC 5322 defines a complex email address specification that is extremely hard to validate with a single regex. This pattern covers 99% of practical email addresses while avoiding false negatives for edge cases.
Should I validate email format on the client or server?
Both. Client-side regex validation provides immediate feedback to users, but server-side validation is essential for security and data quality. Never rely solely on client-side validation.