HTML Form Validation Guide (Native + UX Patterns)

Good validation catches mistakes before they cost you — a mistyped email you can never reply to, an empty “required” field, a phone number in the wrong shape. This guide covers native HTML5 validation, the Constraint Validation API for custom messages, and the UX patterns that make errors feel helpful instead of hostile.

Native HTML5 validation

Before reaching for JavaScript, use what the browser gives you free. These attributes validate on submit and show a native message:

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

<input
  type="text"
  name="zip"
  pattern="[0-9]{5}"
  title="Five-digit ZIP code"
  required
/>

<input type="number" name="quantity" min="1" max="10" required />

Custom messages with the Constraint Validation API

The default messages are generic. To control the wording while keeping native behaviour, use setCustomValidity():

const email = document.querySelector('input[name="email"]');

email.addEventListener('invalid', () => {
  if (email.validity.valueMissing) {
    email.setCustomValidity('We need an email to reply to you.');
  } else if (email.validity.typeMismatch) {
    email.setCustomValidity('That doesn’t look like a valid email.');
  }
});

// Clear the custom message as soon as the user edits the field,
// otherwise it sticks and blocks a now-valid value.
email.addEventListener('input', () => email.setCustomValidity(''));

UX patterns that don’t frustrate

• Validate on blur, not on every keystroke. Yelling at someone mid-typing is hostile. Wait until they leave the field.
• Show errors inline, next to the field — not in a summary alert far from the problem.
• Keep the value. Never clear a field because it was invalid; let the user fix, not retype.
• Use the right input type (email, tel, number) so mobile keyboards adapt.
• Disable nothing on submit until you’ve checked validity — a greyed-out button with no explanation is worse than an error.

Make errors accessible

Validation and accessibility go together: error messages need to be announced to screen readers, and invalid fields need aria-invalid and a programmatic link to their message. See the accessible forms checklist for the markup, and grab ready-made expressions from the input pattern cheatsheet.