The Ultimate Regex for Email Validation - HTML5, Python & JS

An email regex checks whether text matches a chosen pattern. It does not query DNS, test a mailbox or prove that a user controls an address. For most web forms, start with a native email input and a maintained server-side validator. Use a custom expression only when its accepted input policy is explicit and tested.

Use the browser's email input for basic feedback

<label for="email">Email address</label>
<input id="email" name="email" type="email" required
       autocomplete="email">

The browser applies its email-input validity rules; it does not establish mailbox existence. Client-side validation can be bypassed, so validate again on the server. The HTML specification defines the email input's behavior.

A limited JavaScript pattern, with its counterexamples

// A deliberately limited shape check, not an RFC validator.
const shape = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
console.assert(shape.test('alex+news@example.com'));
console.assert(!shape.test('alex@@example.com'));
console.assert(shape.test('alex..smith@example.com')); // false positive
console.assert(!shape.test('"alex smith"@example.com')); // excluded form

This expression requires non-whitespace text around a single at sign and a dot in the domain portion. It is intentionally incomplete: it accepts consecutive dots in the local part and excludes some quoted forms. It is not an official RFC validator or an exact implementation of the HTML email-input algorithm.

The equivalent exercise in Python

import re

shape = re.compile(r"[^\s@]+@[^\s@]+\.[^\s@]+")
assert shape.fullmatch("alex+news@example.com") is not None
assert shape.fullmatch("alex@@example.com") is None
assert shape.fullmatch("alex@example.com\n") is None
assert shape.fullmatch("alex..smith@example.com") is not None  # false positive

fullmatch requires the complete input to match. Decide separately whether surrounding whitespace should be trimmed. The false-positive assertion is deliberate: it demonstrates why a passing test against this pattern is not a complete syntax verdict.

Build a test set before selecting a pattern

• Common addresses and plus tags should follow the application's documented policy.
• Missing local parts, extra at signs and unexpected whitespace should receive clear feedback.
• Internationalized domains and local parts need deliberate library and transport support.
• Quoted addresses and unusual valid forms may require a different parser policy.
• Long or adversarial strings should not consume unbounded processing time.

A pattern that works for a handful of examples has not demonstrated universal coverage. Do not attach an accuracy percentage without a defined dataset and reproducible evaluation. Keep test cases with the code so later changes cannot silently narrow accepted customer addresses.

Know which question regex cannot answer

A syntactically acceptable string may refer to a retired mailbox, a temporary address or an accept-all domain. Conversely, rejecting a string with an overly restrictive expression can exclude a legitimate user. No adjustment to a text pattern can establish current domain routing or the identity of a reader.

Use Python validation or Node.js validation for implementation, and the limits of syntax checking for the evidence and decision model. For sending outcomes, distinguish permanent and temporary failures.

Explore the related Email Awesome workflow and review its current setup before implementing it.