Email Address Validator

How this validator works

This page validates an email address by testing it against a single regular expression (regex) in JavaScript. The goal is to catch the most common formatting mistakes (missing @, invalid domain labels, illegal characters) while staying permissive enough for everyday addresses.

What “valid” means here

“Valid” on this page means the address matches the regex pattern below. It does not guarantee the mailbox exists, that the domain can receive mail, or that messages will be delivered. Real deliverability requires additional checks such as: confirming the address by email, verifying DNS records (MX), or server-side SMTP validation.

Rules checked (practical subset)

• One @ symbol separating a local part and a domain.
• The local part allows common characters used in real addresses (letters, digits, dots, and symbols like + and _).
• The domain is made of labels separated by dots (e.g., example + .com).
• Each domain label starts and ends with an alphanumeric character; hyphens may appear in the middle.
• Domain label length is constrained to typical DNS limits (up to 63 characters per label).

Formula / pattern used

The JavaScript function isValidEmail() uses this regex (shown here for transparency):

^[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])?)*$

This is inspired by the syntax described in RFC 5322, but it intentionally avoids rarely-used features such as comments, folding whitespace, and fully quoted local parts. That trade-off keeps the validator fast, readable, and aligned with what most sign-up forms accept.

Worked examples

Try these inputs to see how the rules behave:

1. [email protected] → Valid. The plus sign is allowed in the local part, and the domain labels are well-formed.
2. bad@@example.com → Invalid. The pattern expects exactly one @ separator.
3. [email protected] → Invalid. A domain label cannot begin with a hyphen.
4. missing-at-symbol.com → Invalid. There is no @ separating local part and domain.

Assumptions and limitations

Email standards allow many edge cases that are uncommon on the modern web. For example, quoted local parts like "john..doe"@example.com can be valid per the RFC, and internationalized email (EAI) can allow Unicode characters. This tool focuses on the mainstream ASCII-style addresses most users type.

Examples of valid and invalid addresses

Understanding email syntax (plain-language overview)

An email address has two logical parts separated by an at sign. The portion before the at sign is the local part, and the portion after is the domain. In everyday terms:

address = local-part + “@” + domain

The local part typically identifies a mailbox name at the provider. It often contains letters and numbers, and many providers also allow symbols such as + for tagging (sometimes called plus addressing). The domain identifies where mail should be routed. Domains are governed by DNS rules: labels are separated by dots, can include hyphens, and have length limits.

This validator is designed for quick client-side feedback. It helps reduce typos and formatting errors, but it should be paired with server-side validation and confirmation emails in real applications.

Deep dive: email validation in the real world

Email validation sounds simple—check for an @ and a dot, then move on—but real email addressing is the product of decades of standards work, operational constraints, and user expectations. This section is intentionally detailed so that developers and curious users can understand what this calculator does, what it does not do, and why those choices are reasonable for a browser-only tool.

At a high level, there are three different questions people mix together when they say “validate an email address.” First is syntax: does the string look like an email address according to a defined grammar? Second is domain validity: does the domain exist, and is it configured to receive mail (for example, via DNS MX records)? Third is mailbox existence: does the specific mailbox actually exist and accept messages? This page focuses on the first question only—syntax—because it can be done instantly, offline, and without leaking user input to a server.

Syntax itself has layers. The formal specification for message format and address syntax is described in RFC 5322, and related documents cover SMTP transport, DNS, and internationalization. The full RFC grammar allows features that are rarely used on the modern web, such as comments in parentheses, quoted strings with unusual characters, and folding whitespace. Many production systems intentionally reject those edge cases because they complicate parsing and can create confusing user experiences. For example, an address like john.doe(comment)@example.com may be valid per the RFC, but most users would not recognize it as a normal address, and many providers would not issue such an address to begin with.

The regex used by this validator is a pragmatic compromise. It accepts a broad set of characters in the local part that are common in real addresses, including + for tags, _ for readability, and a range of punctuation that appears in legacy systems. It also enforces a domain structure that matches DNS hostname rules: labels separated by dots, each label starting and ending with a letter or digit, and hyphens allowed only in the middle. This prevents common mistakes such as [email protected] or [email protected], which are not valid hostnames.

It is also worth noting what the browser does before JavaScript runs. The input field uses type="email", which can trigger built-in validation and mobile keyboard optimizations. However, browser implementations vary, and built-in checks are not always consistent across platforms. That is why the JavaScript regex is the authoritative check for the result shown on this page. The form handler prevents submission and updates the result text in the #email-result element so screen readers can announce changes via aria-live="polite".

Local part details: what characters are allowed and why

The local part is everything before the @. In many systems it maps to a mailbox name, a user account, or an alias. The RFC allows a set of “atext” characters (letters, digits, and certain symbols). In practice, most providers support a subset that is easy to type and easy to communicate verbally. This validator allows letters and digits plus these common symbols: . ! # $ % & ' * + - / = ? ^ _ ` { | } ~. That list covers typical addresses like [email protected], [email protected], and [email protected].

Dots deserve special attention. Many providers allow dots in the local part, but they often impose additional rules such as “no consecutive dots” or “no dot at the beginning or end.” The regex here is permissive about dots because it is designed to be broadly compatible with common web forms, not to mirror the policy of a single provider. If you are integrating this logic into a sign-up flow, consider whether you want to add stricter dot rules to reduce ambiguous or confusing addresses.

Domain details: labels, length limits, and common pitfalls

The domain is everything after the @. It is not just a “website name”; it is a DNS name that can have multiple labels. For example, [email protected] has three labels: mail, example, and com. DNS rules limit each label to 63 characters and the full domain name to 255 characters (including dots). The regex enforces the per-label structure by requiring labels to start and end with an alphanumeric character and allowing up to 61 characters in the middle that may include hyphens.

A frequent user error is accidentally including spaces or punctuation copied from a document, such as [email protected], with a trailing comma. Another common issue is pasting an address with surrounding angle brackets like <[email protected]>. Those formats can appear in email clients, but they are not the raw address itself. This validator expects the plain address only.

Internationalized domains and internationalized email (EAI)

Modern email can involve internationalized domain names (IDNs). A domain like münich.example can be represented in DNS using Punycode, which looks like xn--mnich-kva.example. Many systems accept the Punycode form even if they do not accept the Unicode form. This validator is oriented toward ASCII input and will typically accept the Punycode representation because it is made of letters, digits, and hyphens.

Internationalized email addresses (EAI) go further by allowing Unicode characters in the local part (before the @), such as 用户@例子.公司. Full EAI support requires Unicode-aware parsing and depends on server capabilities. Because this tool is meant to be a lightweight, offline-friendly checker, it does not attempt to validate EAI addresses. If your application targets audiences who use EAI, you should use a dedicated library and confirm server-side support.

Why regex validation is useful (and why it is not enough)

Regex validation is useful because it catches typos early. If a user types [email protected] (a common transposition) the regex will still mark it as syntactically valid, because it cannot know the user’s intent. But it will catch obvious structural errors like name.example.com (missing @) or name@@example.com (double @). That immediate feedback reduces frustration and prevents avoidable bounces.

However, syntax validation cannot confirm deliverability. A domain may exist but not accept mail. A mailbox may be disabled. Some servers accept all recipients during SMTP (a “catch-all” domain) and later discard unknown mailboxes. Some providers intentionally do not reveal whether a mailbox exists to reduce spam and account enumeration. For these reasons, the most reliable way to confirm an address is to send a confirmation email with a link or code and require the user to complete the verification step.

Privacy and security considerations

This calculator performs all checks locally in your browser. The address you type is not transmitted by this page because the submit handler calls preventDefault() and only updates on-page text. That said, if you copy this code into a production site, remember that client-side validation is not a security boundary. Always validate and sanitize inputs on the server as well, and consider rate limiting and abuse prevention for sign-up and password reset flows.

Also be careful about how you display user input. This page uses textContent to write the result message, which avoids HTML injection. If you ever choose to echo the entered email back into the page (for example, “[email protected] is valid”), keep using textContent rather than innerHTML.

Practical guidance for developers

If you are building a sign-up form, consider a layered approach:

• Client-side syntax check (like this page) to catch obvious mistakes quickly.
• Server-side syntax check using the same or slightly stricter rules to ensure consistency.
• Confirmation email to prove the user can receive messages at that address.
• Optional domain checks (DNS MX lookup) if you want to reduce obvious fake domains, while recognizing it can block some valid setups.

Keep your error messages clear and actionable. “Invalid email address” is fine for a generic tool, but in an application you might provide hints such as “Please include an @ symbol” or “Domain labels cannot start with a hyphen.” Avoid being overly strict about top-level domains; new TLDs are introduced regularly, and users may have addresses on uncommon domains.

FAQ

Why does my address pass here but fail on another site?

Different sites use different patterns. Some are overly strict and reject valid characters like + or newer top-level domains. Others require a dot in the domain or enforce a minimum TLD length. This tool aims to be practical, but it is not the only possible policy.

Does this tool check if the domain exists?

No. It only checks formatting. Domain existence and mail routing require DNS lookups (e.g., MX records) and are typically done server-side.

Is my input sent to a server?

No. The validation runs locally in your browser. The form handler prevents submission and only updates the result text on the page.

Can I use this regex everywhere?

You can use it as a starting point, but you should align validation with your product requirements. If you need to support quoted local parts, comments, or EAI, you will need a different approach than a simple ASCII-focused regex. If you only need to catch obvious typos, this pattern is often sufficient.