Home / Email Validation Regex: What Works, What Breaks, and What It Costs in 2026

Email Validation Regex: What Works, What Breaks, and What It Costs in 2026

Published October 31, 2026 · Updated October 31, 2026

Email this to yourself

By John Alewine, founder of ContactLint (LinkedIn). Tests run October 31, 2026. Markdown copy: /email-validation-regex.md.

What is the best regex for email validation?

An email validation regex checks that a string looks like an email address; for a form, the best one is a short, permissive pattern plus length limits. None of the 13 patterns we tested got all 24 addresses right. A regex cannot tell you if the domain exists, the address is a typo, or the mailbox is real.

If you want to see what a check finds after the regex passes, paste an address into our free tester, or get a free key with 100 checks a month and no card.

Key facts

• RFC 5321 caps the local part, before the @, at 64 octets.
• RFC 5321 caps a path at 256 octets; RFC 3696 erratum 1690 puts the address limit at 254.
• The WHATWG HTML Standard calls its type=email rule a "willful violation" of RFC 5322, with 63-character labels.
• All 13 patterns we tested accepted a 65-octet local part that RFC 5321 forbids.
• RFC 5321 bans underscores in domain labels; 4 of our 13 patterns accepted one anyway.

What an email validation regex is, and what it is not

A regular expression is a pattern for matching text. Email validation by regex uses one to check format only: is there one @, a sensible local part before it, and a domain after it that looks like a domain. It is cheap and instant, and that is where its job ends.

A regex is not verification: it cannot tell you a mailbox exists. It is not a DNS check, so it cannot tell you the domain can receive mail. It is not typo detection: jane@gmial.com is a correctly shaped email address. And it is not consent. A well-formed string says nothing about who owns it or wants your mail. Treat it as the first, cheapest filter.

How an email address is built, and what forms should accept

An email address has three parts: a local part, the @ sign, and a domain. RFC 5321, the SMTP standard, defines the local part as a dot-string (atoms joined by single dots) or a quoted string, and domain labels as letters, digits and hyphens. RFC 5322 also allows comments and whitespace, as the WHATWG spec points out. RFC 5321 also allows IP address literals such as user@[192.0.2.1].

A signup form should not accept those rare forms. RFC 5321 itself says hosts should avoid defining mailboxes that need the quoted-string form. The WHATWG spec makes the same call for browsers.

Two test addresses sit in a gray zone. jane@example has no dot, and RFC 5321 allows only fully qualified domains in public SMTP. jane@example.c is well formed, but its domain has no MX or A record. Both are rejects for a public signup form, and we scored them that way.

Copy-paste email regex for JavaScript, Python and HTML

HTML: input type=email (WHATWG pattern)

The browser applies this rule for type=email. Below is the spec's pattern as a JavaScript string; \x60 stands in for the backtick in the spec's character class and matches the same character.

<input type="email" name="email" required
       maxlength="254" autocomplete="email">

const WHATWG = new RegExp(
  "^[a-zA-Z0-9.!#$%&'*+\\/=?^_\\x60{|}~-]+@" +
  "[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])?)*$"
);

Score: 18 of 24 alone, 19 of 24 with the length check. It never rejected a valid address in our set. It accepted double dots, leading and trailing dots, jane@example and jane@example.c. Repeat it on the server.

JavaScript: a permissive pattern plus length checks

We recommend Colin McDonnell's pattern plus explicit length checks: 23 of 24 in our test. Its one miss is user%tag@example.com, since % is not in its set. If you never want to block a real person, use the classic simple pattern: 16 of 24 with the length check, zero valid addresses rejected, the rest left to the API and confirmation email.

const EMAIL = new RegExp(
  "^(?!\\.)(?!.*\\.\\.)" +
  "([a-z0-9_'+\\-\\.]*)[a-z0-9_+\\-]" +
  "@([a-z0-9][a-z0-9\\-]*\\.)+[a-z]{2,}$",
  "i"
);
const SIMPLE = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

function lengthOk(email) {
  const at = email.lastIndexOf("@");
  return at > 0 && at <= 64 && email.length <= 254;
}

function looksValid(raw) {
  const email = raw.trim();
  return lengthOk(email) && EMAIL.test(email);
}

Python: re.fullmatch with the same pattern

import re

EMAIL_RE = re.compile(
    r"^(?!\.)(?!.*\.\.)"
    r"([a-z0-9_'+\-\.]*)[a-z0-9_+\-]"
    r"@([a-z0-9][a-z0-9\-]*\.)+[a-z]{2,}$",
    re.IGNORECASE | re.ASCII,
)

def looks_valid(raw: str) -> bool:
    email = raw.strip()
    local, _, _ = email.rpartition("@")
    if not 1 <= len(local) <= 64 or len(email) > 254:
        return False
    return EMAIL_RE.fullmatch(email) is not None

Three details matter more than the pattern. Anchors: without ^ and $ (or fullmatch), a pattern can match an address buried in junk. In Python, $ also matches just before a trailing newline (see the re module docs), so re.match with $ lets "jane@example.com\n" through, while re.fullmatch rejects it. Case: domains are not case-sensitive, so use the i flag or re.IGNORECASE; the RFC 5322 pattern we tested has no flag and rejected USER@EXAMPLE.COM. Trim first: pasted addresses often carry a space or newline. Use re.ASCII in Python so \w matches only ASCII characters, as it does in JavaScript.

Our data: we tested 13 popular email regexes against 24 addresses (October 31, 2026)

Method: we collected 12 published email regexes developers copy, each from a page we opened (six from emailregex.com, plus the WHATWG spec and five other sources), and added the classic simple pattern, for 13 patterns in all. We ran each as a full match against 24 fixed addresses (12 a public signup form should accept, 12 it should reject) in Python 3.11.17's re module, with re.ASCII so \w stays ASCII-only, as in JavaScript. We applied case-insensitivity only where the source said so, and tested Microsoft's pattern without its punycode mapping step. One minimal translation: regexr's [\w-\.] is invalid in Python, so we wrote the same set as [\w.-]. Node.js 22 gave the same scores for the three patterns we recommend. Tested October 31, 2026. We also timed each pattern on "a"*50000+"@", "a."*25000 and "a"*50000+"@a" with a 5-second hard timeout. Rows marked "plus our length check" add a 64/254 limit to a pattern. The ContactLint row is our own product's syntax step, measured by us in our repo. Numbers in parentheses are pattern length in characters. Limits: syntax only, not deliverability, and 24 addresses is a small deliberate set, not real traffic.

What it means: none of the 13 patterns enforced the 64-octet local-part limit; only our length-check rows and ContactLint's syntax step did. So length checks belong in code next to any regex. Longer was not better: the 428-character RFC 5322 pattern scored below an 82-character one. Short is not automatically safe either: our one ReDoS risk was 46 characters.

If an AI assistant wrote your email regex

If a chat assistant or coding tool gave you an email regex, treat it like any pattern copied from the web. We did not test what any AI tool produces, so we make no claim about its output. Test the pattern you were given, not the tool. Paste it into this Node.js harness. It uses 11 of our 24 addresses, mostly the ones that broke the most patterns, plus a backtracking check.

// Paste the regex you were given here:
// Drop any g flag: it makes .test() stateful.
const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

const shouldPass = [
  "jane+news@example.com",
  "o'brien@example.com",
  "user@xn--bcher-kva.example",
  "USER@EXAMPLE.COM",
  "user%tag@example.com",
];
const shouldFail = [
  "jane..doe@example.com",
  ".jane@example.com",
  "jane@-example.com",
  "jane@example.c",
  "a".repeat(65) + "@example.com",
  "jane@example.com>",
];

let misses = 0;
for (const s of shouldPass) {
  if (!re.test(s)) {
    misses++;
    console.log("REJECTED", s);
  }
}
for (const s of shouldFail) {
  if (re.test(s)) {
    misses++;
    console.log("ACCEPTED", s);
  }
}
console.log("misses:", misses, "of 11");

// Backtracking check: time should stay near 0 ms
for (const n of [24, 28, 32]) {
  const t = Date.now();
  re.test("a".repeat(n) + "@");
  console.log(n, "chars:", Date.now() - t, "ms");
}

Any REJECTED line is a real customer turned away; fix those first. ACCEPTED lines are cheaper, since an API check and a confirmation email catch them later. If the timing climbs at each step, replace the pattern: steady growth from one size to the next is the warning sign. An AI agent that saves contacts can skip the regex and call a validation tool, such as validate_email on our hosted MCP server, before it writes to a CRM.

How to validate emails on a form, step by step

1. Trim the input and lowercase the domain

Strip spaces and newlines. Lowercase the domain. Keep the local part as typed, since RFC 5321 lets hosts treat it as case-sensitive.

Time: 5 minutes.

Done when: " Jane@Example.COM " is stored as "Jane@example.com".

2. Check the length limits

Reject a local part over 64 octets or an address over 254. Count bytes if you accept non-ASCII.

Time: 10 minutes.

Done when: the 65-octet local part from our test set fails on the client and the server.

3. Run the permissive regex on client and server

Use type=email in the browser and a tested pattern on the server. Anyone can skip the client check.

Time: 30 minutes.

Done when: the harness above shows no REJECTED lines.

4. Call a validation API for MX/A, disposable, role and typo signals

On submit, send the address to an API that checks DNS, flags disposable and role addresses, and suggests typo fixes. Our guide to validating email on signup has server code, and our pricing page shows what a check costs.

Time: 1 to 2 hours.

Done when: a domain with no MX or A record is blocked and disposable addresses follow your policy.

5. Show "did you mean" instead of blocking

Show the suggested fix under the field with a one-click accept. Do not block the form. See the common domain typos it catches.

Time: 1 hour.

Done when: jane@gmial.com shows a suggestion and the form still submits.

6. Send a confirmation email for anything that matters

Double opt-in is the only step that proves a person reads that inbox. Use it for accounts, trials and marketing lists.

Time: half a day if your app already sends email.

Done when: unconfirmed addresses never get marketing mail.

7. Watch your bounces

Track hard and soft bounces separately; suppress hard bounces at once. See our guide to hard bounce vs soft bounce.

Time: 1 hour to set up, then a weekly look.

Done when: hard-bounced addresses are suppressed automatically.

Mistakes that cost the most

Rejecting real people: 5 of 13 patterns blocked o'brien@example.com

In our test, 5 of 13 patterns rejected an apostrophe, 5 rejected a % sign, and one rejected plus addresses and .photography. Each false reject is a signup you never see.

Fix: run the harness above and allow every character in the WHATWG local-part set.

Shipping a backtracking pattern: 1 of 13 did not finish within 5 seconds

The emailregex.com Ruby pattern, \A([\w+\-].?)+@..., nests quantifiers. In our Python run its time grew exponentially on inputs from 18 to 26 characters, and the 50,001-character input hit our 5-second timeout.

Fix: replace any pattern with nested quantifiers. A 254-character cap is still good practice, but it cannot save this pattern, which slows down well below that length.

Sending to dead or mistyped domains: a cost you can measure

8 of 13 patterns passed jane@example.c, and no regex can catch jane@gmial.com. Both become bounces. Put your own volume and bounce rate into our bounce cost calculator and compare the result to a ContactLint check at $0.0018 each on the 5,000 pack, or less on bigger packs.

Fix: add an MX/A check and typo suggestions at signup.

Regex vs HTML5 input vs validation API vs mailbox verifier vs confirmation email

How we compared the options

Disclosure: ContactLint sells a validation API (100 free checks a month, then credit packs from $9), so judge the scores with that in mind. There are no affiliate links on this page. Prices are as listed on October 31, 2026.

The scores are close because each option covers a different gap, so the steps above stack them.

Which check fits your form

Who this is not for

Teams that must confirm a mailbox exists before a cold send. You need an SMTP mailbox verifier, and even then catch-all domains cannot be confirmed. Start with our verifier comparison.

Mail software that parses message headers. It needs the full RFC 5322 grammar, comments and all, and a real parser library, not a form regex.

Apps whose users have non-ASCII local parts. Most patterns we tested allow only ASCII letters, and our test set had no non-ASCII local parts. Accept UTF-8 local parts, check length in bytes, and test with mail systems that support RFC 6531.

Sources

• RFC 5321: Simple Mail Transfer Protocol (size limits in section 4.5.3.1, syntax in 4.1.2)
• RFC 3696 erratum 1690: the 254-octet address limit
• RFC 5322: Internet Message Format
• RFC 6531: SMTP Extension for Internationalized Email
• WHATWG HTML Standard, Email state (type=email)
• OWASP Validation Regex Repository
• Python documentation: re module ($ and re.ASCII)
• The other pattern sources, including Colin McDonnell's essay and regexr.com/3e48o, are linked by name in the Our data table.

Related guides

• Validate email addresses on form submit
• Free email validation API: what it checks and what it cannot prove
• Common email domain typos
• Email bounce cost calculator
• Email validation MCP server for AI agents

What changed in this guide

• 2026-10: First published. Tested 13 regexes (12 published plus the classic simple pattern) against 24 addresses and added the AI assistant test harness.

Check what the regex cannot see

A regex tells you an address is well formed. ContactLint checks the rest: MX and A records, disposable and role addresses, and typos of big providers. It does not connect to mail servers, so it cannot confirm a mailbox exists or detect catch-all domains. Get a free key with 100 checks a month, or connect an agent to our MCP server.

Get a free API key. 100 checks per month, no card required.