How to Validate Email Addresses in HTML Forms

The email field is the most important field in most forms — it's how you reply, deliver a download or confirm a sign-up. A typo means a lost lead. But over-strict validation rejects real addresses and frustrates people. Here's how to strike the balance.

Step 1: Use type="email"

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

This one attribute gives you:

• A format check before submit (something like local@domain).
• The email keyboard on phones, with @ and . keys.
• Autofill from the browser and password managers (with autocomplete="email").
• Correct semantics for screen readers.

What type="email" actually accepts

Browsers follow a deliberately simple rule from the HTML standard. It accepts:

• jane@example.com ✓
• jane.doe+news@sub.example.co.uk ✓
• jane@localhost ✓ — no dot required in the domain

And rejects:

• jane ✗
• jane@ ✗
• jane @example.com ✗ — spaces
• jane@@example.com ✗

The surprise for most people is that jane@localhost passes. It's valid on internal networks, but on a public website you probably want a domain with a dot.

Step 2 (optional): Require a dot in the domain

Add a pattern to require at least one dot after the @:

<input id="email" name="email" type="email" autocomplete="email" required
       pattern="[^@\s]+@[^@\s]+\.[^@\s]+"
       title="Enter an email address like name@example.com">

Keep it loose. Real addresses can contain +, ', hyphens, many subdomains and new top-level domains like .studio or .photography.

Why you shouldn't chase the "perfect" email regex

The official email syntax is enormously permissive — it allows quoted strings, comments and characters most people have never seen in an address. Regexes that try to match it fully are hundreds of characters long and still wrong in edge cases. Regexes that are too strict reject real customers:

Overly strict rule	Real address it rejects
TLD must be 2–4 letters	name@company.solutions
No + allowed	jane+receipts@gmail.com
No apostrophes	o'connor@example.ie
Letters only before @	j.smith-2@example.com

A format check can't tell you whether an address exists anyway. asdf@asdf.com passes every regex.

Step 3: Catch common typos

Most bad emails aren't malformed — they're misspelt: gmial.com, hotmial.com, yahoo.co. A gentle "Did you mean…?" suggestion fixes far more errors than a strict pattern.

<input id="email" name="email" type="email" required aria-describedby="email-hint">
<p id="email-hint" class="hint" hidden></p>

const COMMON = {
  'gmial.com': 'gmail.com', 'gmai.com': 'gmail.com', 'gmail.co': 'gmail.com',
  'hotmial.com': 'hotmail.com', 'hotmal.com': 'hotmail.com',
  'yahoo.co': 'yahoo.com', 'yaho.com': 'yahoo.com',
  'outlok.com': 'outlook.com', 'iclod.com': 'icloud.com',
};

const email = document.getElementById('email');
const hint = document.getElementById('email-hint');

email.addEventListener('blur', function () {
  const [local, domain] = email.value.trim().toLowerCase().split('@');
  const fix = domain && COMMON[domain];
  hint.hidden = !fix;
  if (fix) {
    hint.innerHTML = 'Did you mean <button type="button">' + local + '@' + fix + '</button>?';
    hint.querySelector('button').onclick = function () {
      email.value = local + '@' + fix;
      hint.hidden = true;
    };
  }
});

It's a suggestion, not an error — the person can still submit what they typed.

Step 4: Clean up the value

Small fixes prevent avoidable failures:

email.addEventListener('change', function () {
  email.value = email.value.trim();
});

Don't lowercase the part before the @ — technically it can be case-sensitive, even though almost no providers treat it that way. Lowercasing the domain is safe.

Step 5: Validate on the server too

Browser checks can be bypassed, so the receiving end must check the format again. Some servers also check that the domain has mail (MX) records — a cheap way to catch name@gmail.con style mistakes.

Step 6: Confirm the address for anything important

The only way to know an address works and belongs to the person is to send it a message:

• Newsletters: double opt-in — they click a link to confirm.
• Accounts: a verification link or a one-time code.
• Contact forms: an automatic reply. If it bounces, you know the address was wrong.

With Formclick, you can turn on an autoresponder (Pro plan) so every visitor gets a confirmation as soon as they submit. And because the field is named email, your notification's reply-to is set to the visitor, so you can answer with one click.

What not to do

• Don't ask people to type their email twice. Many paste the same typo into both fields. A typo suggestion and a confirmation email work better.
• Don't block free email providers on general forms — plenty of real customers use Gmail.
• Don't block paste in the email field.
• Don't reject + addresses — people use them to filter mail.

The recommended setup

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email" required
       pattern="[^@\s]+@[^@\s]+\.[^@\s]+"
       title="Enter an email address like name@example.com"
       aria-describedby="email-hint">
<p id="email-hint" class="hint" hidden></p>

Plus a typo suggestion, server-side validation and a confirmation email. Learn the wider picture in HTML Form Validation Explained.