How to Validate an Email Address Format (Free Online Tool)

Email addresses look simple, but the rules behind what makes one valid are surprisingly complex. Developers who try to write their own email regex often discover this the hard way — either accepting garbage data or rejecting real addresses from legitimate users.

This guide explains exactly what a valid email address looks like, what the common mistakes are, and how to test any address format instantly.

The anatomy of a valid email address

Every email address has two parts separated by an @ symbol:

localpart@domain.tld

For example: john.doe@example.com

• Local part: john.doe — everything before the @
• Domain: example.com — the mail server's domain name

Both parts have specific rules about what characters are allowed.

Rules for the local part

The local part (before the @) can contain:

• Uppercase and lowercase letters (A–Z, a–z)
• Digits (0–9)
• Dots (.) — but not at the start, end, or consecutively
• Hyphens (-)
• Underscores (_)
• Plus signs (+) — commonly used for email filtering, like user+newsletter@example.com
• Percent signs (%)

Valid local parts:

• john.doe
• user+tag
• first_last
• user123

Invalid local parts:

• .john (starts with a dot)
• john. (ends with a dot)
• john..doe (consecutive dots)
• john doe (contains a space)
• john@doe (contains a second @)

Rules for the domain part

The domain (after the @) must follow these rules:

• Contains letters, digits, hyphens, and dots
• Each label (section between dots) must be between 1 and 63 characters
• Labels cannot start or end with a hyphen
• The entire domain cannot start or end with a dot
• Must include at least one dot (to separate domain from TLD)
• The top-level domain (TLD) must be at least 2 characters

Valid domains:

• example.com
• mail.example.co.uk
• my-company.org

Invalid domains:

• example (no TLD)
• -example.com (starts with hyphen)
• example-.com (label ends with hyphen)
• example..com (consecutive dots)

The most common email format mistakes

Most invalid email addresses fall into one of these categories:

1. Missing the @ symbol

johndoeexample.com — without an @, nothing after the first character group gets treated as a domain, so validation fails immediately.

2. Multiple @ symbols

john@doe@example.com — only one @ is allowed per address.

3. Spaces in the address

john doe@example.com or john@example .com — spaces are not valid in standard email format. Quoted local parts ("john doe"@example.com) technically allow spaces per RFC 5322, but this format is not accepted by almost any real-world system.

4. Missing or invalid TLD

user@example has no TLD. user@example.c has a single-character TLD, which is not currently assigned. The TLD must be at least 2 characters.

5. Consecutive dots

john..doe@example.com — consecutive dots in the local part are invalid.

6. Domain starting with a dot

user@.example.com — a domain cannot begin with a dot.

How to validate email format with regex

Regular expressions (regex) are the standard tool for email format validation. The pattern most commonly used in production code is:

^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$

Breaking it down:

Part	Meaning
^	Start of string
[a-zA-Z0-9._%+\-]+	Local part: letters, digits, dots, underscores, percent, plus, hyphens (one or more)
@	The required @ symbol
[a-zA-Z0-9.\-]+	Domain: letters, digits, dots, hyphens (one or more)
\.	A literal dot before the TLD
[a-zA-Z]{2,}	TLD: letters only, at least 2 characters
$	End of string

You can test this pattern — and any other regex — against email addresses using the FixTools Regex Tester. Paste the pattern and test multiple addresses to see which ones match.

What this pattern catches

It correctly rejects:

• Missing @
• Multiple @
• Spaces in the address
• Domains without TLDs
• Single-character TLDs

What this pattern does not catch

This pattern accepts some technically invalid addresses (like a..b@example.com with consecutive dots in the domain) and rejects some technically valid ones (like "user name"@example.com with a quoted local part). For production validation, this tradeoff is usually the right call — the complex edge cases rarely appear in real user-submitted data.

HTML5 email input validation

Modern browsers provide built-in email validation through the HTML type="email" input attribute:

<input type="email" name="email" required>

The browser applies its own validation pattern when the form is submitted. This validation is less strict than RFC 5322 — it accepts most common formats and rejects obvious errors. The exact pattern varies by browser but generally follows the same logic as the regex above.

This approach requires zero JavaScript and gives users instant browser-native error messages. The downside is that it can only be customized with the pattern attribute.

JavaScript email validation

For JavaScript validation (either client-side or Node.js server-side), the standard approach is:

function isValidEmail(email) {
  const pattern = /^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/;
  return pattern.test(email);
}

isValidEmail('user@example.com');     // true
isValidEmail('user@example');         // false
isValidEmail('userexample.com');      // false
isValidEmail('user@.example.com');    // false

For server-side validation in Node.js, many teams use the validator library, which includes a battle-tested isEmail() function that handles edge cases correctly.

Format validation vs. existence validation

Email format validation tells you whether the address looks valid. It does not tell you whether the address exists or whether someone can actually receive email there.

Validation type	What it checks	How to do it
Format validation	Syntax: local part, @, domain, TLD	Regex or HTML5 input
DNS validation	Does the domain's MX record exist?	DNS lookup
SMTP validation	Does the mailbox accept connections?	SMTP handshake
Confirmation email	Does the user have access to the inbox?	Send a verification link

For most applications — sign-up forms, lead capture, contact forms — format validation combined with a confirmation email is the right approach. SMTP verification is used by email list cleaning tools and bulk senders who need to validate large lists without actually sending emails.

Extracting email addresses from text

If you have a block of text — a document, a web page, or a data export — and need to pull out all email addresses from it, the Extract Emails tool on FixTools does this in one step. Paste any text and it finds every pattern matching an email address format, without requiring you to write a regex yourself.

This is useful for:

• Pulling contact emails from scraped web content
• Finding addresses in exported reports or documents
• Cleaning datasets where emails are mixed with other data

Client-side vs. server-side validation

A common mistake is relying only on client-side validation. Since client-side JavaScript runs in the user's browser, it can be bypassed by anyone who opens the browser's developer tools and submits the form directly.

Always validate on the server side as well. The rule is:

• Client-side validation = UX improvement (instant feedback, no page reload)
• Server-side validation = security requirement (cannot be bypassed)

Both should run. If a user bypasses your client-side check, server-side validation is what prevents bad data from entering your database.

Validate email format now

To test an email address or a regex pattern against multiple addresses, use the FixTools Regex Tester. Paste the pattern above, enter your test addresses, and see immediately which ones pass and which fail.

For extracting email addresses from a document or text block, the Extract Emails tool handles the regex work automatically.