Regex for Email Validation: Patterns That Actually Work

Email validation with regex is deceptively tricky. Here are battle-tested patterns from simple to comprehensive — and when to use each one.

The Problem with Email Validation

Email validation sounds simple: check if a string looks like a valid email address. In practice, it's one of the most debated topics in software development because the RFC 5322 specification for email addresses is surprisingly permissive.

Technically valid email addresses include:

• "john doe"@example.com — quoted local parts with spaces
• user+tag@example.com — plus addressing
• user@123.123.123.123 — IP address domains
• user@[IPv6:2001:db8::1] — IPv6 literal domains
• very."(),:;<>@[\\]".VERY."very@\\ "unusual@strange.example.com — yes, really

Trying to match the full RFC spec with regex is impractical (the complete pattern is thousands of characters). Instead, we need pragmatic patterns that catch 99.9% of real-world emails.

Level 1: The Simple Pattern (Good Enough for Most Cases)

^[^\s@]+@[^\s@]+\.[^\s@]+$

This pattern checks for:

• One or more non-whitespace, non-@ characters before the @
• An @ symbol
• One or more non-whitespace, non-@ characters
• A dot
• One or more non-whitespace, non-@ characters after the dot

Matches: user@example.com, first.last@company.co.uk, user+tag@mail.org

Rejects: @example.com, user@, user@example, no spaces@here.com

This is the pattern we recommend for most form validation. It's readable, fast, and catches obvious invalid inputs without rejecting uncommon-but-valid addresses.

Level 2: The Standard Pattern (More Thorough)

^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$

This adds character-class restrictions:

• Local part: alphanumeric, dots, underscores, percent, plus, hyphen
• Domain: alphanumeric, dots, hyphens
• TLD: at least 2 alphabetic characters

Matches: john.doe@example.com, user+tag@company.co.uk

Rejects: user@.com, user@com, user@example.c

Level 3: The HTML5 Pattern (Browser Standard)

The HTML5 specification defines its own email validation pattern, used by <input type="email">:

^[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])?)*$

This is more permissive in the local part (allowing special characters per RFC) while being strict about domain label formats. If you want to match what browsers validate, use this.

Implementation Examples

JavaScript

// Simple — recommended for most use cases
function isValidEmail(email) {
  const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return pattern.test(email);
}

// Standard — stricter character validation
function isValidEmailStrict(email) {
  const pattern = /^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/;
  return pattern.test(email);
}

// Usage
console.log(isValidEmail('user@example.com'));      // true
console.log(isValidEmail('not-an-email'));           // false
console.log(isValidEmail('user@example'));           // false

Python

import re

def is_valid_email(email: str) -> bool:
    pattern = r'^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$'
    return bool(re.match(pattern, email))

# Usage
print(is_valid_email('user@example.com'))     # True
print(is_valid_email('bad@.com'))             # False
print(is_valid_email('user+tag@mail.co.uk'))  # True

PHP

// PHP has a built-in filter — prefer it over regex
$email = 'user@example.com';

if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
    echo "Valid email";
} else {
    echo "Invalid email";
}

Java

import java.util.regex.Pattern;

public class EmailValidator {
    private static final Pattern EMAIL_PATTERN =
        Pattern.compile("^[a-zA-Z0-9._%+\\-]+@[a-zA-Z0-9.\\-]+\\.[a-zA-Z]{2,}$");

    public static boolean isValid(String email) {
        return EMAIL_PATTERN.matcher(email).matches();
    }
}

Common Mistakes in Email Regex

1. Restricting TLD Length

Don't limit TLDs to 2-4 characters. Modern TLDs like .technology, .photography, and .international are perfectly valid. Use {2,} not {2,4}.

2. Forgetting Plus Addressing

Many patterns reject user+tag@gmail.com. Plus addressing is widely used for filtering — make sure your pattern allows + in the local part.

3. Not Handling Subdomains

Addresses like user@mail.company.co.uk have multiple dots in the domain. Your pattern should handle any number of domain segments.

4. Case Sensitivity

Email addresses are case-insensitive in the domain part and technically case-sensitive in the local part (though virtually no provider enforces this). Always compare case-insensitively.

Beyond Regex: Proper Email Validation

Regex alone cannot determine if an email address is actually deliverable. For production systems, combine approaches:

1. Regex check — catch obviously invalid formats (the patterns above)
2. MX record lookup — verify the domain has mail servers configured
3. Confirmation email — the only way to truly verify an address is to send a message with a confirmation link

Don't over-validate with regex. A slightly permissive pattern that sends a confirmation email is better than a strict pattern that rejects valid users.

Frequently Asked Questions

Which email regex should I use in production?

For form validation, the simple pattern ^[^\s@]+@[^\s@]+\.[^\s@]+$ is our recommendation. It's fast, readable, and doesn't reject unusual-but-valid addresses. Pair it with a confirmation email for actual verification.

Can regex fully validate an email per RFC 5322?

Technically yes, but the resulting pattern is thousands of characters long and impractical. No production system uses the full RFC regex. Pragmatic patterns that catch 99.9% of cases are the standard approach.

Should I validate emails on the client or server?

Both. Client-side validation (with <input type="email"> or regex) gives instant feedback. Server-side validation ensures security — never trust client-side validation alone.

Related reading: Online Regex Tester Guide · Regex Cheat Sheet & Examples