How to Use Regex for Email Validation

March 22, 2026 · 9 min read

You're building a signup form and need to check if the user typed a valid email address. Your first thought: regex. It seems simple — until you discover that the "official" email regex from RFC 5322 is over 6,000 characters long. So which pattern should you actually use?

This guide walks through email validation with regex from simple to complex, shows you the common pitfalls, and explains why regex alone is never enough for real email validation.

The Simple Pattern (Good Enough for Most Cases)

Here's the pattern most developers should start with:

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

Let's break it down:

^ — start of string
[^\s@]+ — one or more characters that aren't whitespace or @ (the local part)
@ — literal at sign
[^\s@]+ — the domain name
\. — a literal dot
[^\s@]+ — the top-level domain
$ — end of string

This catches the vast majority of obviously-invalid inputs (missing @, missing domain, spaces) while being permissive enough to accept valid but unusual addresses.

JavaScript Implementation

function isValidEmail(email) {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

// Test it
console.log(isValidEmail("user@example.com"));     // true
console.log(isValidEmail("user.name+tag@gmail.com")); // true
console.log(isValidEmail("user@sub.domain.co.uk"));  // true
console.log(isValidEmail("not-an-email"));           // false
console.log(isValidEmail("missing@domain"));         // false
console.log(isValidEmail("@no-local-part.com"));     // false

Python Implementation

import re

def is_valid_email(email):
    pattern = r'^[^\s@]+@[^\s@]+\.[^\s@]+$'
    return bool(re.match(pattern, email))

# Test it
print(is_valid_email("user@example.com"))      # True
print(is_valid_email("user+filter@gmail.com")) # True
print(is_valid_email("bad email@test.com"))    # False
print(is_valid_email("no-at-sign.com"))        # False

HTML5 Built-In Validation

Before reaching for regex, know that HTML5's <input type="email"> already validates emails using a pattern based on RFC 5322:

<form>
  <input type="email" required>
  <button type="submit">Submit</button>
</form>

This gives you free browser-level validation with proper error messages. The internal pattern browsers use is:

^[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 thorough than our simple pattern — it validates the character set of the local part and enforces domain label length limits.

The Stricter Pattern

If you need more validation than the simple pattern but don't want the full RFC monster, this middle-ground pattern works well:

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

What it checks:

Local part — letters, digits, dots, underscores, percent, plus, hyphen
Domain — letters, digits, dots, hyphens
TLD — at least 2 letters (catches user@domain.c as invalid)

What it misses:

Quoted local parts like "john doe"@example.com (valid per RFC but rare)
IP address domains like user@[192.168.1.1]
International domain names (IDN) with non-ASCII characters

Common Patterns That Are Wrong

These patterns appear frequently in tutorials and Stack Overflow answers, but they reject valid emails:

Pattern Issue	What It Rejects	Why That's Wrong
TLD max length of 3-4	user@example.museum	TLDs like .museum, .photography, .technology exist
No + in local part	user+tag@gmail.com	Plus addressing is widely used for filtering
No consecutive dots	user@sub..domain.com	Correct to reject — but some patterns reject first.last@domain.co.uk too
Requiring exactly one dot in domain	user@mail.co.uk	Many valid domains have multiple dots
ASCII-only	user@example.xn--...	Internationalized domains are increasingly common

The RFC 5322 "Complete" Regex

For reference, here's the regex that fully implements RFC 5322 email validation. You should not use this in production — it's shown here to illustrate why a simpler approach is better:

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

This is unmaintainable, hard to debug, and most of the edge cases it handles (quoted strings, IP literal domains, escape sequences) are vanishingly rare in practice.

Why Regex Alone Isn't Enough

Even a perfect regex can't tell you whether an email address actually works. Regex validates format, not deliverability.

A complete email validation strategy has three layers:

Format check (regex) — catches typos and obviously wrong input. Fast, runs client-side.
DNS check — verify the domain has MX records. user@ggmail.com passes regex but fails DNS because ggmail.com doesn't accept email.
Confirmation email — the only way to prove an address works is to send an email and have the user click a link. This is the gold standard.

// Node.js: Check DNS MX records
const dns = require('dns');

function checkEmailDomain(email) {
  const domain = email.split('@')[1];
  return new Promise((resolve, reject) => {
    dns.resolveMx(domain, (err, addresses) => {
      if (err || !addresses || addresses.length === 0) {
        resolve(false); // No MX records
      } else {
        resolve(true);  // Domain accepts email
      }
    });
  });
}

// Usage
const valid = await checkEmailDomain("user@gmail.com");  // true
const invalid = await checkEmailDomain("user@ggmail.com"); // false

Best Practices for Email Validation

Use the simple regex for client-side — ^[^\s@]+@[^\s@]+\.[^\s@]+$ is enough to catch typos
Use HTML5 type="email" — free browser validation, no regex needed
Be permissive, not restrictive — rejecting a valid email is worse than accepting an invalid one
Validate server-side too — never trust client-side validation alone
Send a confirmation email — the only reliable way to validate
Don't validate TLD length — new TLDs are created regularly
Allow + addressing — many users rely on it for filtering
Trim whitespace — users often paste emails with leading/trailing spaces

Bottom line: Use ^[^\s@]+@[^\s@]+\.[^\s@]+$ for basic format checking, pair it with HTML5 type="email" for client-side validation, and always send a confirmation email for real validation. Don't overthink the regex — the simple pattern catches 99% of bad input.

Test your email regex patterns instantly
Paste your regex, test against sample emails, see matches highlighted in real time.
Open Regex Tester