DevLab
Regex

Regex for Email Validation: The Right Approach

Learn why perfect email regex is impossible, what a practical validation pattern looks like, and when to use client-side vs server-side validation.

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

  1. Client-side UX: type="email" or simple regex to catch obvious typos before submission
  2. Server-side format check: Reject addresses missing @ and a dot — not to be strict, but to prevent garbage data
  3. 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

Practice with these tools

More Learning Topics