Email Regex Validation in JavaScript: Patterns You Can Copy, Edge Cases and What to Check After the Regex

The best email regex validation in JavaScript is a short, forgiving pattern that catches obvious mistakes, followed by a server-side check and a confirmation email. A regular expression can tell you whether text looks like an email address. It cannot tell you whether the domain receives mail or whether the mailbox exists. This guide gives you patterns you can copy, explains why the "perfect" email regex does not exist, shows tests and edge cases, and describes what to do after the regex passes.

A simple email regex that works for most forms

For a sign-up form, you want to reject obvious mistakes without rejecting real addresses. This pattern requires some text, an at sign, some text, a dot and some text, with no spaces:

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

function looksLikeEmail(value) {
  const v = String(value).trim();
  return v.length <= 254 && EMAIL_RE.test(v);
}

looksLikeEmail("[email protected]");        // true
looksLikeEmail("info@@example.com");    // false
looksLikeEmail("sam@localhost");        // false (no dot in the domain)
looksLikeEmail("name [email protected]");   // false (space)

It accepts a few things that are not deliverable, such as "[email protected]", and that is fine, because later checks will catch them. What matters is that it does not reject real addresses. Rejecting a real customer is a worse error than accepting a bad one.

The HTML5 pattern

Browsers validate input fields of type email using a pattern defined in the HTML Standard. You get it for free with <input type="email">, and you can call input.checkValidity() in JavaScript. The same pattern, written as a regex, looks like this:

const HTML5_EMAIL_RE =
  /^[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])?)*$/;

It is stricter about allowed characters, and it limits each part of the domain to 63 characters. It still accepts "user@localhost", because the standard allows a domain without a dot, so add a check for a dot if you need one. The HTML Standard calls this a "willful violation" of the full email specification, which shows how hard the full rules are to apply.

Why a perfect email regex does not exist

• The real grammar is complicated. RFC 5322 allows quoted local parts, comments and unusual characters. A regex that follows it fully is long and hard to maintain.
• Valid is not the same as deliverable. "[email protected]" has a valid shape and may not exist.
• Addresses can contain non-ASCII characters. Internationalised addresses, described in RFC 6531, allow UTF-8 in the local part and domain. An ASCII-only pattern rejects them. Decide whether to support them and test.
• Length limits matter. A local part can be at most 64 characters and the whole address 254.
• Complex patterns can be slow. Patterns with nested repetitions can take very long to fail on crafted input, a problem known as ReDoS. Keep patterns simple and linear.

Test cases to run

What to do after the regex passes

1. Trim and normalise. Remove spaces from the ends and lower-case the domain. Do not change the local part, which may be case-sensitive in theory.
2. Run a server-side check. Never rely on browser validation alone, because a request can be sent to your server without the form. Repeat the pattern on the server.
3. Check the domain. Confirm that the domain exists and publishes mail servers, using DNS MX lookups.
4. Catch typos. Suggest a fix for common slips, such as gmial.com for gmail.com.
5. Check the mailbox where possible. A verification service can ask the receiving server whether the address exists, without sending a message. See email verification tools.
6. Send a confirmation email. It proves the person owns and can read the address. Read double opt-in for sign-up forms.

Calling a validation API from JavaScript

Use a validation API on your server, so that your key stays secret. Our validation API checks the syntax, looks up the domain's mail servers and can return a typo suggestion in under a second. The sketch below shows the shape; use the authentication described in the API reference.

// server-side (Node.js): never put API keys in browser code
const res = await fetch("https://api.example.com/v1/validate", {
  method: "POST",
  headers: { "Content-Type": "application/json" /* add your API key as documented */ },
  body: JSON.stringify({ email: "[email protected]" })
});
const data = await res.json();
// e.g. { result: "risky", fix: "gmail.com" }
if (data.fix) { /* ask the user: did you mean [email protected] ? */ }

The URL above is a placeholder. For occasional checks you can use our free email validator, which reads DNS only and does not test whether a particular mailbox exists.

Validating on the client and the server

• Client: use type="email" and the simple pattern for fast feedback. Show a helpful message, such as "That does not look like an email address", and let people fix it.
• Server: repeat the check, because clients can be bypassed, and add the DNS and typo checks.
• After sign-up: confirm by email, then keep the address clean with regular checks. See list hygiene.

Validation and deliverability

Bad addresses cause bounces, and a high bounce rate harms your sender reputation. A modest regex and a domain check keep the worst addresses out at the door. Read email validation before sending for the full set of checks, and email bounce types to see what happens when a bad address gets through.

Common mistakes in email validation code

• Limiting the top-level domain to two to four letters. Many valid domains end in longer extensions, so such a pattern rejects real people.
• Rejecting the plus sign. Many people use [email protected] to sort their mail. Rejecting it loses sign-ups.
• Forgetting to trim. A pasted address often has a space at the end, and the user sees an error they cannot explain.
• Lower-casing the whole address blindly. The domain is case-insensitive. The local part is technically case-sensitive, although nearly all providers treat it as case-insensitive. Store what the user typed, and compare in a case-insensitive way if you choose to.
• Showing an unhelpful message. "Invalid input" does not help. Say what is wrong and how to fix it.
• Blocking the form on a failed network check. If a validation service is slow or down, let the sign-up go through and validate later.

Writing validation messages people can act on

Good messages are specific, polite and visible to everyone, including people who use screen readers. Place the message next to the field, link it to the field with an accessible description, and avoid colour alone as the signal. Instead of "Invalid email", write "This address is missing an @ sign. Did you mean [email protected]?" For typo suggestions, show the corrected address as a button the person can accept with one click. Always let people keep what they typed if they are sure, because rare, valid addresses exist that no rule anticipates.

Testing your validation

Keep a list of test addresses in your code and run it on every change: a few ordinary ones, several with plus tags and dots, long ones near the limits, ones with unusual but valid characters, and several clearly invalid ones. If your product serves international customers, include internationalised addresses in the list, and decide in advance whether they are accepted. A short table-driven test catches most regressions, and it documents what your form accepts for the next developer.

References and further reading

• RFC 5322: Internet Message Format
• RFC 5321: Simple Mail Transfer Protocol
• RFC 6531: SMTP Extension for Internationalized Email
• HTML Standard: valid email address