Email Validation Regex

Anatomy of an Email Address Regex

Email addresses consist of three distinct parts: a local part, the @ symbol, and a domain part. A standard production-ready regex pattern for email checking looks like this:

Let's break down how this pattern validates each component:

• Local Part ([a-zA-Z0-9._%+-]+): Matches letters, numbers, and allowed symbols (dots, underscores, percent, plus, dashes) one or more times.
• Domain Name ([a-zA-Z0-9.-]+): Matches alphanumeric characters, dashes, and dots. The dot allows subdomains (e.g. mail.domain.com).
• Top Level Domain (\.[a-zA-Z]{2,}): Matches a literal dot followed by at least two letters (like .com, .org, or .engineering).

Common Pitfalls in Email Regex

Over-restricting emails is one of the most common developer mistakes. Here are three things to watch out for:

• Forgetting Plus Addressing: Many users use tags (e.g. user+newsletters@gmail.com) to filter emails. Ensure your local part includes the plus (+) symbol.
• Restricting TLD length: Older regex patterns enforce a 2-to-4 character length on the domain extension (e.g., .[a-zA-Z]{2,4}). This rejects modern top-level extensions like .london, .photography, or .tech. Use {2,} instead.
• Unrealistic RFC 5322 Compliance: The full RFC 5322 email specification is extremely complex, permitting nested comments, quotes, and IP domain literals, resulting in a regex that is hundreds of lines long. For 99% of web applications, a clean, readable pattern is highly preferred.