Regex for Email Validation: A Practical Pattern

For ordinary signup and contact forms, start with this practical email regex:

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

It requires text before @, text after it, at least one dot in the domain portion, and no whitespace. It catches common typing mistakes without pretending that a regular expression can prove an inbox exists.

What the pattern means

Read the regex from left to right:

• ^ starts at the beginning of the input.
• [^\s@]+ requires one or more characters that are neither whitespace nor @.
• @ requires the separator.
• A second [^\s@]+ requires the first domain portion.
• \. requires a literal dot.
• The final [^\s@]+ requires text after the dot.
• $ ends at the end of the input.

Paste the pattern and sample addresses into the regex tester to see every match and failure. If the syntax itself is unfamiliar, the practical regex tutorial explains anchors, character classes, and quantifiers.

JavaScript email validation example

Remove only surrounding whitespace before testing:

const EMAIL_SHAPE = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

function hasValidEmailShape(input) {
  const email = input.trim();
  return email.length <= 254 && EMAIL_SHAPE.test(email);
}

The length cap provides a sensible input boundary and avoids accepting an unlimited string. Apply a compatible rule on the server too: browser validation improves feedback, but anyone can submit an HTTP request without your form.

Why not use the biggest possible regex?

Internet email syntax has decades of history. Quoted local parts, internationalized domains, comments, and other rarely encountered forms make a complete standards-oriented pattern enormous. A huge regex is difficult to review, can behave differently across engines, and often still rejects addresses that real providers accept.

Overly narrow patterns are worse. These common rules reject legitimate users:

• Allowing only letters and numbers before @ rejects name+tag@example.com.
• Requiring a two- or three-letter suffix rejects modern longer top-level domains.
• Assuming exactly one domain dot rejects subdomains.
• Rejecting non-ASCII characters excludes internationalized addresses your mail provider may support.

Your form's job is to catch obvious mistakes and protect system boundaries. Your mail system's job is to decide what it can deliver.

Syntax, domain, mailbox, and ownership

Email “validation” actually describes four different checks:

1. Shape: Does the input resemble an address? Regex or type="email" can answer this.
2. Domain: Does the domain publish mail-routing records? A DNS lookup can help, though some domains accept mail through fallback behavior.
3. Mailbox: Will a server accept this recipient? Providers often hide this to prevent address harvesting, so remote probing is unreliable.
4. Ownership: Can this user receive a message at the address? Only a confirmation link or code establishes that.

A regex answers only the first question. For accounts, payments, or notifications, send a time-limited verification link and do not mark the address verified until the user opens it.

HTML forms and accessible errors

Use <input type="email" autocomplete="email" inputmode="email"> so browsers provide basic checks and an appropriate mobile keyboard. Avoid adding a restrictive HTML pattern unless it exactly matches your server policy; two conflicting validators create confusing failures.

When input fails, say “Enter an email address such as name@example.com.” Do not show “Value failed /^[…]$/.” Keep the entered value, associate the error with the field, and focus the first invalid field after submission.

Normalization and storage

Trim whitespace accidentally pasted around the address. Lowercase the domain because DNS names are case-insensitive. Be conservative with the part before @: although major services ignore case and some ignore dots, those behaviors are provider-specific and should not be applied globally.

Do not remove +tag suffixes. They are valid, useful, and may distinguish how a user routes mail. If duplicate-account prevention matters, verify the address first and define an explicit product policy rather than silently rewriting identities.

Test cases worth keeping

Test normal addresses, plus tags, subdomains, surrounding whitespace, double @ signs, missing suffixes, and inputs longer than your limit. Add Unicode cases if your mail vendor supports internationalized email. A generated pattern is a starting point—the regex generator can help sketch one—but tests are what turn it into a stable contract.

The practical answer

Use a simple regex to catch obvious shape errors, validate again on the server, and send a confirmation message to prove ownership. The best email validator is not the cleverest pattern; it is a short, understandable check followed by a real delivery workflow.