Form validation

What form validation does

Form validation means checking what a person typed into a form before you accept it. Each check is a rule. For example:

• A signup form needs an email address.
• A booking form needs a date after today.
• A coupon box takes only a code shaped like SAVE20.

The browser can run many of these checks for you. Its tools for this are called the Constraint Validation API. A constraint is one rule for one field. You write the rules as HTML attributes. Then JavaScript can:

• read input.validity to see which rules fail,
• call checkValidity() to test a field or a whole form,
• call setCustomValidity() to add a rule of your own.

1function passwordMessage(password, confirm) {2  return password === confirm ? "" : "Passwords must match";3}4 5console.log(passwordMessage("otter", "owl"));6console.log(passwordMessage("otter", "otter"));

The function compares two passwords. Line 2 gives back an empty string, "", when they match. When they don't match, it gives back the message Passwords must match. Here the empty string means "no error".

So line 5 prints Passwords must match, and line 6 prints an empty line. Later in this lesson, you'll pass this same result to confirm.setCustomValidity().

Start with HTML. The browser already knows many common rules. These rules also help other tools understand the field, such as phone keyboards, password managers, and screen readers.

Each field has a validity object. It holds one flag for each rule. A flag is a true-or-false value, and it is true when its rule fails. Here are the main rules and their flags:

• required means the field can't be empty. An empty required field turns on validity.valueMissing.
• type="email" and type="url" want an email address or a web address. A value in the wrong shape turns on typeMismatch.
• type="number" and the date types accept only a number or a date.
• pattern gives a shape that the whole value must match. It is skipped when the field is empty. You'll learn the pattern language in the Regular expressions lesson. For now, read [A-Z]{3} as "three capital letters".
• min, max, and step set which numbers or dates are allowed.
• minlength and maxlength set how long the text may be. Browsers turn on tooShort only after a person has typed the value.

1const form = document.createElement("form");2const field = document.createElement("input");3field.required = true;4field.type = "email";5field.minLength = 5;6form.append(field);7document.body.append(form);8 9console.log(field.validity.valueMissing);10field.value = "asha@";11console.log(field.validity.typeMismatch);12field.value = "ash";13field.dispatchEvent(new Event("input", { bubbles: true }));14console.log(field.validity.tooShort);

Lines 1 to 7 make a form with one email field. The field is required, must be an email address, and needs at least 5 characters (minLength). Then:

• Line 9 prints true for valueMissing, because the field is still empty.
• Line 10 puts asha@ in the field. That is not a full email address, so line 11 prints true for typeMismatch.
• Line 12 puts ash in the field, which has only 3 characters. Even so, line 14 prints false for tooShort.

Why false? A value set by code doesn't count as typed, even with the made-up input event on line 13. To see tooShort turn on, type into the dashboard in the next section.

The pattern must match the whole value, from the first character to the last. So [A-Z]{3} accepts ABC but not ABCx. Current browsers read the pattern in a strict mode, the regular expression v flag. In that mode, some punctuation inside square brackets needs a backslash before it.

Some fields skip validation completely. For those fields, input.willValidate is false, and the browser never checks their rules. This happens for:

• disabled fields,
• read-only text fields,
• fields with type="hidden".

1<label>2  Age3  <input name="age" type="number" min="13" max="120" step="1" required>4</label>

This field needs a whole number from 13 to 120. Line 3 holds all the rules. Each wrong value turns on a different flag:

• An empty field turns on valueMissing, because of required.
• 12 turns on rangeUnderflow, which means "below min".
• 121 turns on rangeOverflow, which means "above max".
• 13.5 turns on stepMismatch, because step="1" allows only whole numbers.

The browser checks these rules before your submit code runs.

1const pin = document.createElement("input");2pin.pattern = "[0-9]{6}";3pin.value = "1234567";4console.log(pin.validity.patternMismatch);5pin.value = "123456";6console.log(pin.validity.patternMismatch);7 8const tickets = document.createElement("input");9tickets.type = "number";10tickets.min = "2";11tickets.max = "10";12tickets.step = "2";13tickets.value = "3";14console.log(JSON.stringify({ underflow: tickets.validity.rangeUnderflow, step: tickets.validity.stepMismatch }));

Line 2 says the PIN must be exactly six digits. Line 4 prints true for patternMismatch, because 1234567 has seven digits. The pattern must match the whole value, so six of the seven digits is not enough. Line 6 prints false, because 123456 matches.

Lines 8 to 13 make a ticket field that allows 2 to 10, in steps of 2. So the allowed values are 2, 4, 6, 8, and 10. Line 14 prints {"underflow":false,"step":true}. The value 3 is inside the range, so rangeUnderflow is false. But 3 is not one of the steps, so stepMismatch is true.

1const field = { value: "", required: false, pattern: /^[A-Z]{3}$/ };Run2const validity = check(field);3console.log(validity.valueMissing);4console.log(validity.patternMismatch);5console.log(validity.valid);

Compare the first two choices. In both, the field is empty and has a pattern. The pattern flag stays false in both, because the pattern waits for a value. Only required decides if an empty field is allowed.

So if an empty field should be an error, add required. If the field is optional, people can leave it blank without seeing a format error.

Every field that takes part in validation has a validity property. Its value is a ValidityState object: a checklist with one flag for each kind of failure. It also has one last flag, valid. valid is true only when every other flag is false.

The dashboard below shows the real flags from your browser. It reads them when the page loads and each time you type.

It also shows validationMessage: the error text the browser writes for that field. The browser chooses those words, so they differ between browsers and languages. For the text in your own app, write your own messages.

1<form>2  <input name="name" required>3  <input name="email" type="email" required>4  <input name="site" type="url">5  <input name="tickets" type="number" min="1" max="10" step="2">6  <input name="code" minlength="3" maxlength="8" pattern="[A-Z]{3}[0-9]{2}">7  <input name="day" type="date" min="2026-01-01">8</form>

Try these:

• Leave Name empty: valueMissing turns on.
• Type abc in Email: typeMismatch turns on.
• Type 4 in Tickets: stepMismatch turns on, because the allowed values are 1, 3, 5, 7, and 9.
• Type ab in Code: tooShort turns on, because you typed it yourself. patternMismatch turns on too.

HTML attributes check one field at a time. But many real rules compare two fields, or use your app's own data. For example:

• The two passwords must match.
• The end date must come after the start date.
• A username can't be one that your app keeps for itself.

For rules like these, use setCustomValidity(message). It works like this:

• Any message that isn't empty marks that one field as invalid. It turns on validity.customError.
• setCustomValidity(""), with an empty string, removes the error.
• The error stays until you remove it. The empty string is the only way to turn it off.

1confirm.addEventListener("input", () => {2  const match = password.value === confirm.value;3  confirm.setCustomValidity(match ? "" : "Passwords must match");4});5 6form.checkValidity();  // boolean, fires invalid7form.reportValidity(); // boolean, asks browser to show UI

Three methods have similar names. Read each row as: what you call, what you get back, and what it does.

1const form = document.createElement("form");2const email = document.createElement("input");3email.type = "email";4email.required = true;5form.append(email);6document.body.append(form);7let invalidEvents = 0;8form.addEventListener("invalid", () => invalidEvents++, true);9 10console.log(form.checkValidity());11console.log(form.reportValidity());12console.log(invalidEvents);

The email field is required and empty, so both checks fail. Line 10 prints false for checkValidity(), and line 11 prints false for reportValidity().

The invalid event is the browser's signal that a field failed a check. Line 8 counts these events, and line 12 prints 2: one event for each check. checkValidity() only tests. reportValidity() tests and also shows the browser's error bubble, a small pop-up next to the field.

1const form = document.createElement("form");2const email = document.createElement("input");3email.required = true;4form.append(email);5document.body.append(form);6form.addEventListener("invalid", (event) => {7  event.target.setCustomValidity("Email is required");8}, true);9form.checkValidity();10console.log(email.validationMessage);

Line 6 listens for invalid on the form. Line 9 checks the form, and the empty field fails. So the listener runs, and line 7 sets your own message on that field. Line 10 prints Email is required instead of the browser's words.

The invalid event does not bubble up from the field to the form. That is why line 8 passes true. With true, the listener runs in the capture phase, while the event travels down to the field. So a listener on the form still hears it.

To pick a message for a field, follow these steps:

1. Read validity.valid.
2. If it is false, find the first flag that is true.
3. Show your own message for that flag.

Don't use validationMessage as your app's text. The browser chooses its words and its language.

The browser's error bubbles are fine for a quick test. Real apps often want more:

• the same wording on every page,
• a list of all the errors at the top of the form,
• messages in the person's own language,
• each message placed right next to its field.

To do this, add novalidate to the form. It turns off the browser's own bubbles. Then call checkValidity() yourself and show your own messages.

A good message says how to fix the field. Use a real email address, like ada@example.com helps more than Invalid input. Read the same flags as before, and turn each one into a clear instruction.

1<form novalidate>2  <input id="email" type="email" required aria-describedby="email-error">3  <p id="email-error"></p>4  <button>Join</button>5</form>6 7form.addEventListener("submit", (event) => {8  event.preventDefault();9  if (!form.checkValidity()) showFriendlyErrors();10});

1const form = document.createElement("form");2form.noValidate = true;3const email = document.createElement("input");4email.required = true;5form.append(email);6document.body.append(form);7form.addEventListener("submit", (event) => {8  event.preventDefault();9  console.log("submit -> " + form.checkValidity());10});11form.requestSubmit();

Line 2 turns on novalidate. The email field is required and empty. Line 11 calls requestSubmit(), which submits the form the same way a submit button does.

Normally the browser would stop that submit. With novalidate, it reaches your submit listener. But the rules are still there: line 9 prints submit -> false, because checkValidity() still sees the empty field. Use novalidate only when your own code shows an equally clear error.

When should messages appear? Many teams wait for the first submit, so people don't see red errors while they are still typing. After that, they update the messages on input (each edit) or on blur (when the person leaves the field).

CSS has two selectors for this. :invalid matches a field as soon as it breaks a rule, even before the person touches it. The newer :user-invalid matches only after the person has changed the field, in browsers that support it.

A red border alone doesn't help everyone. Some people use only a keyboard. Some use a screen reader, a program that reads the page aloud. Some zoom the page in a lot. They all need the error as text, and the text must be linked to its field in the HTML.

• Set aria-invalid="true" on each field that has an error. This tells screen readers the field is invalid.
• Set aria-describedby on the field to the id of its error text. A screen reader then reads the error together with the field.
• Put a summary of all the errors near the top, with a link to each field.
• After a failed submit, move focus to the first invalid field, or to the summary. Focus is the place where typing goes.
• Make the summary a live region with aria-live="polite". A screen reader then reads new errors aloud when it is free.

1<div role="alert" aria-live="polite" id="error-summary"></div>2<input id="email" required aria-invalid="true" aria-describedby="email-error">3<p id="email-error">Enter your email address.</p>

The form events lesson showed how to move focus and how to handle submit. Validation uses both. Catch the failed submit, show a summary, and move focus. Then keep each message linked to its field while the person fixes it.

Where you will use this

A signup form can use every tool from this lesson:

• The email field has type="email" required.
• The password field has minlength="8".
• The confirm field uses setCustomValidity() to check that the passwords match.
• On submit, your code shows its own summary of the errors.

Other forms use them too. At checkout, min, max, and step check a quantity. In settings, setCustomValidity() can block a username that your app keeps for itself.

Once a form passes, the next lesson, FormData, shows how to collect its values with new FormData(form) and get them ready to send.

1function canCreateAccount(email) {2  const value = String(email ?? "").trim();3  return value !== "" && value.includes("@");4}5 6console.log(canCreateAccount("ada@example.com"));7console.log(canCreateAccount(""));

The server gets plain data, with no browser rules attached. Line 2 turns whatever arrived into a string and removes the spaces at both ends. The ?? part turns null or undefined into an empty string first. Line 3 rejects an empty value and a value with no @.

So line 6 prints true, and line 7 prints false. A real server would use a full email check and its own rules before it creates the account.

Common misconceptions

• "The browser accepted it, so it is safe." Not true. The server must check every rule that matters.
• "pattern makes a field required." No. An empty optional field skips pattern. Add required for that.
• "A custom error removes itself." No. You must call setCustomValidity("") to remove it.
• "validationMessage is good text for my app." It is the browser's text, in the browser's language. When the words matter, map each flag to your own message.
• "A red border is enough." No. People need the error as text, linked to its field, plus a summary and a focus move.

Each row below is a tempting shortcut, and a better habit to use instead.

Key takeaways

• HTML rules such as required and pattern give you a lot of validation before you write any JavaScript.
• validity is a checklist of flags. valid is true only when no rule fails.
• setCustomValidity("message") turns on customError. setCustomValidity("") turns it off.
• checkValidity() only tests. reportValidity() tests and shows the browser's error.
• Your own error messages must work for everyone, and the server must check again.

Form validation is checking form values against rules. The browser helps people fix mistakes first, and the server makes the final check.

Up next: FormData.