Email validation in JavaScript: a working form example

To validate an email address in JavaScript, use an HTML <input type="email"> with required, then call checkValidity() to decide which feedback to show. A passing format check leaves domain, mailbox and ownership questions unanswered. See MDN’s email-input reference.

A form you can try in a browser

Save this example as an HTML file and open it in a browser. Enter one address and select Continue, or press Enter. The example displays the format result locally. Before using it for registration, connect the successful branch to your own server handler.

<form id="email-form" novalidate>
  <label for="email">Email address</label>
  <input id="email" name="email" type="email" autocomplete="email"
         required aria-describedby="email-feedback">
  <p id="email-feedback" aria-live="polite"></p>
  <button type="submit">Continue</button>
</form>

<script>
const form = document.querySelector("#email-form");
const email = document.querySelector("#email");
const feedback = document.querySelector("#email-feedback");

email.addEventListener("input", () => {
  feedback.textContent = "";
  email.removeAttribute("aria-invalid");
});

form.addEventListener("submit", (event) => {
  event.preventDefault();

  if (!email.checkValidity()) {
    const message = email.validity.valueMissing
      ? "Enter an email address."
      : email.validity.typeMismatch
        ? "Enter an address in email format."
        : "Check the email address.";

    feedback.textContent = message;
    email.setAttribute("aria-invalid", "true");
    email.focus();
    return;
  }

  email.removeAttribute("aria-invalid");
  feedback.textContent = "Format accepted. Send the address to your server.";
});
</script>

How the example handles errors

novalidate suppresses automatic submit-time validation; the explicit checkValidity() call still runs. valueMissing identifies an empty required field, and typeMismatch identifies an email-format error. The HTML constraint validation API defines these checks.

The label names the field. On an error, the code writes a specific message, sets aria-invalid and returns focus to the input. aria-describedby associates the feedback with the field, while aria-live="polite" makes changing feedback available to assistive technology. When the person edits the value, the code clears the previous message and invalid state so they can try again. Error feedback does not depend on colour.

If the browser’s own error messages suit your form, set the form to submit by POST to your server handler, then remove novalidate and the JavaScript submit handler. The HTML input already performs the format check; JavaScript is useful here because it controls the wording and placement of the feedback.

Test the format check before connecting a server

Use the following inputs in the example. The results describe this form’s browser validation, without a network request.

After an error, correct the value and submit again. The old error and aria-invalid should clear. Test both the button and the Enter key, since either can submit the form.

The domains are synthetic: RFC 2606 reserves example.com and example.org for documentation. An accepted example cannot demonstrate a real mailbox.

When a custom regex helps

For this form, keep the browser’s email rules and use JavaScript for feedback. A second regex adds another rule to maintain. If your application intentionally restricts addresses to one organisation’s domain, document that as a business requirement and enforce it on the server too.

Keep accepted addresses intact when handing them to the server. In the plus-address test, removing +orders would change the submitted value. This example covers one address under browser input rules; unusual or internationalised formats need a separate support decision and tests across the form, server parser and mail service.

What to do after the browser accepts the format

Send the value to your application server over its normal form or API route. Validate submitted data independently there: a client can bypass browser checks and make a direct request. MDN’s form-validation guide explains this boundary.

In the example, event.preventDefault() cancels submission. The success message is the point where you would add your application’s request. Check its response before advancing the flow, and show a recoverable error if the request fails. The local success message alone must not create an account or mark an address as verified.

Once the server has accepted the format, choose the next check according to the decision you need to make:

The syntax-versus-SMTP comparison helps choose the depth of evidence. A full Emvero check can collect recipient-level SMTP evidence without sending a message. Server restrictions or timeouts can leave the answer unknown, which does not establish that the address is undeliverable. Call the email verification API from your server so its credentials remain private.

For a signup flow, use the signup-form validation guide to decide which results allow the person to continue and when to ask for confirmation.