Why Perfect Email Regex is Impossible
The official email spec (RFC 5321) allows quoted strings, IP address domains, and Unicode in local parts. A fully compliant regex is hundreds of characters long and still incomplete. The practical lesson: email regex should catch obvious mistakes, not be the final authority. The only true validation is sending an email and seeing if it arrives.
Practical Patterns
// Reasonably comprehensive
const emailRegex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*.[a-zA-Z]{2,}$/;
// Simpler — catches the most common mistakes
const simpleEmail = /^[^s@]+@[^s@]+.[^s@]+$/;
The simple pattern catches: missing @, spaces, missing domain. Accepts: user+tag@example.com, user@sub.domain.co.uk. Good enough for most signup forms.
Use the Browser First
<input type="email" required />
The browser's built-in email validation uses a well-tested pattern more comprehensive than most hand-rolled regex. Use type="email" first, and only add custom regex for specific requirements the browser does not handle.
The Three-Layer Approach
- Client-side UX:
type="email"or simple regex to catch obvious typos before submission - Server-side format check: Reject addresses missing @ and a dot — not to be strict, but to prevent garbage data
- Verification email: The only real validation — send a confirmation link
Test Cases to Always Cover
// Must accept:
"user+tag@example.com" // plus addressing
"user@sub.domain.co.uk" // multiple subdomains
// Must reject:
"user@.com" // domain starts with dot
"user@@example.com" // double @
"user example.com" // no @, has space