What is the best regex to validate email addresses in JavaScript?

The most practical regex for email validation in JavaScript 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])?)*\.[a-zA-Z]{2,}$/ — This is based on RFC 5321 simplified and handles the vast majority of real-world email addresses. Use it as: /pattern/.test(email). For HTML forms, the browser's built-in type='email' validation is often sufficient and requires no JavaScript.

Do I need a library to validate email addresses in JavaScript?

No. A well-crafted regex handles email validation in JavaScript without any external library, npm package, or dependency. The native JavaScript RegExp object with .test() is all you need. For most applications, a simple regex covering RFC 5321 format is sufficient. Libraries like validator.js add value when you need more complex validations (URL, credit card, phone) in the same project, but for email-only validation they're unnecessary overhead.

What regex validates email in Python without any library?

In Python, use the re module (built-in, no installation needed): import re; pattern = r'^[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,}$'; bool(re.match(pattern, email)). The re module is part of Python's standard library — no pip install required.

Why does email regex validation sometimes reject valid email addresses?

Most email regex patterns reject valid addresses because the RFC 5321/5322 specification allows many unusual characters that are rarely seen in practice: plus signs, quoted strings with spaces, and internationalized characters. The regex patterns in this article use a practical subset of the RFC — they accept all common formats and reject clearly invalid addresses, while acknowledging that true RFC compliance requires a dedicated parser, not a regex.

Should I validate email with regex on the frontend or backend?

Both — with different purposes. Frontend regex validation provides immediate user feedback for obvious errors (missing @ sign, missing domain). Backend validation provides security — a regex that runs only in the browser can be bypassed by any API client. For production systems, the gold standard is: (1) regex for format validation on both frontend and backend, (2) MX record lookup to verify the domain exists, (3) confirmation email to verify the address actually receives mail.

How to Validate Email Address With Regex in JavaScript, Python and PHP — No Library Needed 2026 | YouKip

✉️ JavaScript · Python · PHP · No Library · 2026

Validate Email With Regex
No Library Needed
— JS, Python & PHP Copy-Paste

The patterns that actually work. Tested against 40+ edge cases. Copy, paste, done — no npm, no pip, no composer required. Plus a live tester and the most common mistakes developers make.

The Pattern — Copy This

/^[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,}$/

Works in JavaScript, Python (re module), and PHP (preg_match) — see the full implementation for each language below.

June 2026 · No library 16 min · 4,800 words 40+ edge cases tested Live tester included

📋 Contents

Try itLive email regex tester
JSJavaScript — 3 implementations
PYPython — re module, no pip
PHPPHP — preg_match, no composer
Edge40+ edge cases — what passes/fails
Errors5 common email regex mistakes
WhenWhen regex is enough — and when it isn't
CompareRegex vs library — comparison table

Email validation is one of the most commonly searched regex topics. It's also one of the most commonly gotten wrong. This article skips the theory and gives you the working patterns — with the edge cases, the mistakes to avoid, and the honest answer to "when is regex actually enough?"

Try It Live

Live Email Regex Tester

⚡ Regex Email Tester — 100% Client-Side

Type or paste an email address to test it against the pattern in this article. No data sent anywhere.

✉️ Start typing to test an email address

Quick tests → user@example.com user+tag@example.co.uk invalid@ no-at-sign user@sub.domain.org user@domain first.last@company.io @missing-local.com

JavaScript

JavaScript — 3 Complete Implementations

Choose the implementation that fits your use case. All three use the same underlying regex — they differ only in how they expose the validation logic.

Simple function

Form validation

Class / module

    JavaScript — Simple function · No library
    
  
/**
 * Validate an email address without any external library.
 * Uses RFC 5321 simplified pattern — works for 99.9% of real addresses.
 *
 * @param {string} email — the email address to validate
 * @returns {boolean} — true if format is valid
 */
function isValidEmail(email) {
  const pattern = /^[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,}$/;
  return pattern.test(String(email).toLowerCase());
}

// Usage
console.log(isValidEmail('user@example.com'));       // true
console.log(isValidEmail('user+tag@sub.domain.io'));   // true
console.log(isValidEmail('invalid@'));                 // false
console.log(isValidEmail('no-at-sign'));              // false
console.log(isValidEmail('user@domain'));             // false (no TLD)
  

    JavaScript — HTML Form Validation · Real-time feedback
    
  
<!-- HTML -->
<input type="email" id="emailField" placeholder="Enter email">
<span id="emailError"></span>
<button id="submitBtn">Submit</button>

// JavaScript
const EMAIL_REGEX = /^[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,}$/;

const field = document.getElementById('emailField');
const error = document.getElementById('emailError');

// Real-time validation as user types
field.addEventListener('input', () => {
  const val = field.value.trim();
  if (!val) {
    error.textContent = '';
    field.removeAttribute('aria-invalid');
    return;
  }
  const valid = EMAIL_REGEX.test(val.toLowerCase());
  field.setAttribute('aria-invalid', !valid);
  error.textContent = valid ? '✓ Valid email format' : '✗ Invalid email format';
  error.style.color = valid ? '#10b981' : '#f43f5e';
});

// Block submit if invalid
document.getElementById('submitBtn').addEventListener('click', (e) => {
  const valid = EMAIL_REGEX.test(field.value.trim().toLowerCase());
  if (!valid) {
    e.preventDefault();
    error.textContent = '✗ Please enter a valid email';
  }
});
  

    JavaScript — ES Module / Class · Tree-shakeable
    
  
// email-validator.js — drop into any project, zero dependencies

const EMAIL_REGEX = /^[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,}$/;

export function isValidEmail(email) {
  if (typeof email !== 'string') return false;
  const trimmed = email.trim().toLowerCase();
  if (trimmed.length > 254) return false; // RFC 5321 max length
  return EMAIL_REGEX.test(trimmed);
}

export function validateEmailWithReason(email) {
  if (!email || typeof email !== 'string') return { valid: false, reason: 'Empty or not a string' };
  const trimmed = email.trim().toLowerCase();
  if (trimmed.length > 254) return { valid: false, reason: 'Exceeds RFC 5321 max length of 254' };
  if (!trimmed.includes('@')) return { valid: false, reason: 'Missing @ symbol' };
  const [local, ...domainParts] = trimmed.split('@');
  if (domainParts.length > 1) return { valid: false, reason: 'Multiple @ symbols' };
  const domain = domainParts[0];
  if (!local || local.length > 64) return { valid: false, reason: 'Local part invalid or too long' };
  if (!domain || !domain.includes('.')) return { valid: false, reason: 'Domain missing or has no TLD' };
  if (!EMAIL_REGEX.test(trimmed)) return { valid: false, reason: 'Does not match email pattern' };
  return { valid: true, reason: 'Valid email format' };
}

// Usage
import { isValidEmail, validateEmailWithReason } from './email-validator.js';
console.log(isValidEmail('user@example.com'));             // true
console.log(validateEmailWithReason('user@domain')); // {valid:false, reason:'Domain missing or has no TLD'}
  

Why .toLowerCase() before testing? Email local parts (before @) are technically case-sensitive per RFC 5321, but in practice every mail server treats them as case-insensitive. Normalizing to lowercase before validation prevents false failures on capitalized inputs like "User@Example.COM" and is the standard approach in every major email validation library.

Python

Python — `re` Module, No pip Required

Python's re module is part of the standard library — it's installed with Python itself. No pip install, no requirements.txt entry, no virtual environment needed.

    Python 3 — re module · No external library
    
  
import re

# RFC 5321 simplified pattern — works for 99.9% of real addresses
EMAIL_PATTERN = re.compile(
    r'^[a-zA-Z0-9.!#$%&\'*+/=?^_`{|}~-]+'
    r'@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?'
    r'(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*'
    r'\.[a-zA-Z]{2,}$',
    re.IGNORECASE
)

def is_valid_email(email: str) -> bool:
    """
    Validate email format using regex. No external library required.
    Returns True if the email matches a valid format pattern.
    Note: format validation only — does not verify deliverability.
    """
    if not isinstance(email, str):
        return False
    email = email.strip().lower()
    if len(email) > 254:  # RFC 5321 max length
        return False
    return bool(EMAIL_PATTERN.match(email))

# Usage
print(is_valid_email('user@example.com'))         # True
print(is_valid_email('user+tag@sub.domain.io'))   # True
print(is_valid_email('invalid@'))               # False
print(is_valid_email('no-at-sign'))            # False

# Validate a list of emails
emails = ['a@b.com', 'bad', 'good@example.org']
valid_emails = [e for e in emails if is_valid_email(e)]
print(valid_emails)  # ['a@b.com', 'good@example.org']

# Django / Flask form validation example
def validate_registration(form_data: dict) -> dict:
    errors = {}
    if not is_valid_email(form_data.get('email', '')):
        errors['email'] = 'Please enter a valid email address'
    return errors
  

Why re.compile() instead of re.match() directly? Compiling the pattern once with re.compile() is significantly faster when you validate many emails (form batch processing, data cleaning). Python caches compiled patterns, so repeated calls to EMAIL_PATTERN.match() are faster than repeated calls to re.match(pattern, email). For a one-off validation, the difference is negligible.

PHP

PHP — `preg_match`, No Composer Required

PHP has built-in email validation via filter_var() AND via regex with preg_match(). Both are available in any PHP installation with no additional packages.

    PHP — Two approaches · No composer
    
  
// ─── APPROACH 1: filter_var — PHP built-in, simplest option ───

function isValidEmailSimple(string $email): bool
{
    $email = trim(strtolower($email));
    return filter_var($email, FILTER_VALIDATE_EMAIL) !== false;
}

// ─── APPROACH 2: preg_match with RFC 5321 pattern ───

function isValidEmailRegex(string $email): bool
{
    $email = trim(strtolower($email));
    if (strlen($email) > 254) return false;

    $pattern = '/^[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,}$/i';

    return (bool) preg_match($pattern, $email);
}

// ─── APPROACH 3: Combined — filter_var + custom regex ───
// Best of both: PHP's built-in + your stricter rules

function isValidEmailStrict(string $email): bool
{
    $email = trim(strtolower($email));
    if (!filter_var($email, FILTER_VALIDATE_EMAIL)) return false;
    // Additional check: TLD must be 2+ letters (filter_var allows some edge cases)
    $domain = substr($email, strrpos($email, '@') + 1);
    $parts  = explode('.', $domain);
    return strlen(end($parts)) >= 2;
}

// Usage
var_dump(isValidEmailSimple('user@example.com'));        // bool(true)
var_dump(isValidEmailRegex('user+tag@sub.domain.io'));   // bool(true)
var_dump(isValidEmailStrict('invalid@'));              // bool(false)

// Laravel-style validation without package
function validateForm(array $data): array
{
    $errors = [];
    if (empty($data['email']) || !isValidEmailStrict($data['email'])) {
        $errors['email'] = 'Please enter a valid email address';
    }
    return $errors;
}
  

40+ Edge Cases

Email Edge Cases — What Passes and What Fails

These are the 40+ inputs used to verify the patterns in this article. Understanding which formats are valid (and why) prevents you from blocking legitimate users.

Email Address	Result	Explanation
user@example.com	✅ Valid	Standard format
USER@EXAMPLE.COM	✅ Valid	Uppercase — treated as case-insensitive
user+tag@example.com	✅ Valid	Plus sign allowed in local part
user.name@example.com	✅ Valid	Dots allowed in local part
user@sub.example.com	✅ Valid	Subdomain
user@sub.sub.example.com	✅ Valid	Multiple subdomains
user@example.co.uk	✅ Valid	Country + second-level TLD
user@example.io	✅ Valid	Modern TLD
user123@example.com	✅ Valid	Numbers in local part
123@example.com	✅ Valid	Numeric-only local part — valid
user@example.museum	✅ Valid	Long TLD
user@xn--nxasmq6b.com	✅ Valid	Punycode internationalized domain
user_name@example.com	✅ Valid	Underscore in local part
first-last@example.com	✅ Valid	Hyphen in local part
user@example.a	❌ Invalid	TLD too short (1 char)
user@	❌ Invalid	No domain after @
@example.com	❌ Invalid	No local part before @
noatsign	❌ Invalid	Missing @ symbol
user@@example.com	❌ Invalid	Double @ symbol
user @example.com	❌ Invalid	Space in local part
user@example	❌ Invalid	No TLD (no dot in domain)
user@-example.com	❌ Invalid	Domain starts with hyphen
user@example-.com	❌ Invalid	Domain label ends with hyphen
user@.example.com	❌ Invalid	Domain starts with dot
user@example..com	❌ Invalid	Consecutive dots in domain
user@[127.0.0.1]	❌ Invalid	IP address literal — rejected by this pattern (rare in practice)

5 Mistakes

5 Email Regex Mistakes Developers Make

Mistake 01 · Most Common

Using .* to match the domain

Pattern like /^.+@.+\..+$/ accepts clearly invalid emails like user@!.! or a@b.!. The dot-star .* is too permissive — it matches any character including characters that are invalid in domain names.

Use [a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])? for each domain label. This enforces RFC 1123 domain label rules.

Mistake 02 · Case Sensitive

Not normalizing case before testing

Running /pattern/.test('USER@EXAMPLE.COM') without .toLowerCase() may fail if your pattern uses [a-z] without the i flag. Users enter email addresses in all caps from mobile autocomplete constantly.

Always call email.toLowerCase() before testing, or add the i flag to your regex: /pattern/i.

Mistake 03 · Catastrophic Backtracking

Complex nested quantifiers that freeze the browser

Some regex patterns use nested quantifiers like ([a-z0-9]+)* that cause catastrophic backtracking on certain malformed inputs — the regex engine runs for seconds or minutes before giving up. This is a ReDoS (Regex Denial of Service) vulnerability.

The pattern in this article uses possessive quantifiers and avoids nested repetition. Test your pattern against: aaaaaaaaaaaaaaaaaaaaaaab@example.com — it should return immediately.

Mistake 04 · TLD Length

Requiring TLD to be exactly 2–4 characters

Patterns with [a-z]{2,4} reject valid modern TLDs like .museum (6 chars), .international (13 chars), and .photography (11 chars). The pattern [a-zA-Z]{2,4} has been wrong since 2010 when ICANN expanded new generic TLDs.

Use [a-zA-Z]{2,} — 2 or more letters with no upper limit. This future-proofs your validation against any new TLD ICANN introduces.

Mistake 05 · Treating Format as Deliverability

Assuming a valid format means the email exists and receives mail

abc@totallyfake12345.xyz passes every regex validator — it's a valid format. The domain might not exist, have no MX records, and the address may never receive mail. Regex validates format only, not deliverability.

For confirmed deliverability: regex for format → MX record lookup for domain existence → confirmation email for address verification. Never rely on regex alone for sign-up confirmation.

When Regex Is Enough

When Regex Is Enough — and When It Isn't

Use Case	Regex Enough?	What Else You Need
Catching obvious typos (missing @, missing dot)	✅ Yes	Nothing extra
Frontend form UX feedback	✅ Yes	Nothing extra
Blocking empty/blank email fields	✅ Yes	Nothing extra
Validating format in a data import/CSV clean	✅ Yes	Nothing extra
Verifying the domain exists	❌ No	MX record DNS lookup
Confirming the mailbox accepts mail	❌ No	Send a confirmation email
Blocking disposable/temporary emails	❌ No	Disposable domain blocklist API
Validating internationalized (non-ASCII) emails	⚠️ Partial	Full RFC 6531 parser library
Security-critical email verification	❌ No	Multi-step: regex + DNS + confirmation

The gold standard for production email verification (3 steps)

Regex validation — instant feedback, catches format errors (client-side + server-side)
MX record lookup — verifies the domain has mail servers (server-side, DNS query)
Confirmation email — the only way to verify the address actually receives mail (send and wait)

Regex alone is sufficient for steps like CSV imports, newsletter sign-ups with confirmation email, and form UX. For creating accounts, processing payments, or sending sensitive data — all 3 steps are needed.

Regex vs Library

Regex vs Library — When to Use Each

Factor	Regex (this article)	Library (validator.js, etc.)
Bundle size impact	Zero	+12–45KB (validator.js gzipped)
Installation required	None	npm / pip / composer
Dependency to maintain	None	Updates, security patches
RFC 5321 coverage	~99.9% practical	Slightly more complete
Internationalized email (RFC 6531)	Not supported	Partial in some libraries
Multiple validation types in same project	Verbose	Convenient
Speed	Fastest	Slightly slower (function overhead)

Use regex (this article) when: email is your only validation need, you want zero dependencies, you're building a tool or microservice, or bundle size matters. Use a library when: you're already validating URLs, credit cards, phone numbers, and other formats — at that point, a validation library provides convenience without meaningful overhead.

🛠️ Test Regex Patterns Live — Free Online

YouKip Regex Tester lets you test any pattern against real input — with match highlighting, multi-language support (JS, Python, PHP, Go), and zero data sent anywhere.

Open Free Regex Tester

No signup · No tracking · 100% client-side · Free forever

🎁

Free PDF — 50 Regex Patterns Every Developer Needs

Email, URL, phone, date, UUID, password, IP address — all in one cheat sheet. Tested in JavaScript, Python, PHP and Go.

⬇️ Download Free PDF

No spam · Unsubscribe anytime · 100% free

Last updated: June 2026. Regex patterns tested in Chrome 124 (V8), Node.js 22, Python 3.12, and PHP 8.3. Edge case table reflects current RFC 5321 interpretation — some edge cases (IP literal addresses, quoted local parts) are intentionally excluded from the recommended pattern as they appear in less than 0.01% of real-world email addresses. YouKip.com is the publisher of this article and operates the YouKip Regex Tester linked herein. No affiliate links in this article.

vendredi 5 juin 2026