Forms · Compared

Inline vs on submit validation

Inline validation checks an answer while the person is at the field, usually as they leave it, and shows any problem beside it. On submit validation waits until the form is sent, then reports every problem at once. Good forms combine them: inline checks for fields that are hard to get right, and a final check on submit.

When an error appears matters almost as much as what it says. Shown too early it scolds people for answers they have not finished typing, and shown too late it sends them hunting back through a form they thought was done.

Indunil Asanka · Co-founder

5 min read · Published 13 September 2026

Inline and on submit validation compared
What changes	Inline validation	On submit validation
When errors appear	As a field is left, or while it is typed	After pressing submit or next
Suits	Fields with rules people often miss, such as usernames, passwords and formats	Short forms and simple fields such as a name or an email
Main risk	Errors that appear before the person has finished typing	A list of errors at the end that people must go back and find
Published evidence	A 2009 study of 22 people found 22% higher success and 42% faster completion for the best inline version	The GOV.UK Design System defaults to it, warning that inline checks can cause problems for slower typists
Accessibility need	Messages announced without moving focus away from the field	An error summary at the top with focus moved to it
Server check still needed	Yes	Yes

What the best known study found

In 2009 Luke Wroblewski published a study run with the London usability firm Etre, in which 22 participants filled in six versions of the same web form: one that validated only on submit and five that validated inline in different ways. Against the submit only version, the best inline version produced a 22% increase in success rates, a 22% decrease in errors, a 31% increase in satisfaction, a 42% decrease in completion time and a 47% decrease in eye fixations. Timing inside the inline versions mattered as much. Checking after a field was left was 7 to 10 seconds faster than the alternatives, while showing messages before and during typing gave longer times, more errors and worse satisfaction.

Which fields benefit

The same study found a split that is easy to overlook. Only 30 to 50% of participants noticed the inline messages on straightforward questions such as name, email and postcode, but 80 to 100% noticed them on hard fields such as a username and password. Its conclusion was that inline validation earns its place on fields that are difficult to complete correctly, not on every field. That matches experience. Nobody needs a green tick for typing their first name, but somebody choosing a password against five rules, or entering a reference number in a strict format, benefits enormously from learning about a problem while they are still looking at the box. The practical approach is to list the fields on a form, mark the two or three where people most often get an answer rejected, and put the inline effort there, leaving everything else to a single clear check at the end.

Why premature errors backfire

The failure most people remember is a field that turns red on the first keystroke. Baymard Institute's e-commerce usability testing quotes participants who felt the form was yelling at them before they had tried to submit anything, and one who asked why the site was calling an email address wrong when they had not finished typing it. Its recommendation is to validate when the person leaves a field, or once a fixed length value such as a card number is complete, and then to update on every keystroke so the error disappears the moment the answer becomes valid. Positive confirmation, such as a tick beside a correct entry, was also appreciated by participants.

The case for waiting until submit

The GOV.UK Design System takes the opposite default. Its guidance is not to validate when the user moves away from a field but to wait until they try to move on, and to add inline validation only when research shows it helps, because it can cause problems for people who type more slowly. When errors are found, it shows an error summary at the top of the page with keyboard focus moved to it, a message beside each field, the word Error added to the page title for screen reader users, and every answer the person already gave kept in place. For long services with short pages, validating each page as it is submitted is effectively inline at the level that matters.

What happens in this builder

Neither form type validates as you type. A classic form checks when it is submitted: the browser runs its own required and number range checks, and a missing required answer brings up a message naming the first field that needs one. A conversational form checks each screen when Next is pressed, which puts the feedback one question at a time. Some rules are checked only by the server. Text length limits on both kinds, and the number range on a conversational form, are enforced after the respondent submits, and on a classic form a length problem found there comes back as a general failure message rather than one pointing at the field, so keep length limits generous. On a conversational form, give a field with strict rules its own screen, so that the message shown when Next is pressed cannot be mistaken for a problem with a different question.

Questions people ask

Should validation run on every keystroke?

Only to remove an error, not to show one. Updating on each keystroke is useful once a message is already visible, because the person sees it vanish as soon as the answer is right. Showing new errors while someone is still typing is what the research consistently finds irritating, and it slows completion rather than speeding it up.

Should the submit button be disabled until the form is valid?

Usually not. A greyed out button gives no reason, so people cannot tell which field is holding them up, and some assume the form is broken. Leaving the button active and explaining the problems when it is pressed is clearer, and it gives screen reader users a message instead of a silent control that does nothing.

Is inline validation accessible?

It can be. The message has to be in text, linked to the field and announced by assistive technology, without pulling focus away from where the person is typing. WCAG requires detected errors to be identified and described in text whichever timing you choose, so colour or an icon on its own does not satisfy the requirement.

What does validate on blur mean?

Blur is the moment a field loses focus, when the person tabs or taps away from it. Validating on blur means checking the answer at that moment, once they have signalled they are finished. It is the timing the 2009 study found fastest, and it avoids the premature errors that come from checking while someone is still typing.

Does inline validation replace checking on the server?

No. Inline checks exist for the respondent's benefit and can be bypassed by anybody who edits the page or sends data directly. Every rule that matters has to be repeated where the submission is received. The inline layer should make that server check rarely fail, not stand in for it.

Do green ticks for correct answers help?

On fields where people are unsure, yes. Participants in checkout testing said a tick reassured them that a long number had been typed correctly. On simple fields a tick adds visual noise without telling anybody something they did not already know, so reserve positive confirmation for the answers that are genuinely easy to get wrong.

Make one with forms

The button opens the generator with this use case already described. Change the wording to match your own.

Create a form with OneCraft

Sources

Written and checked by the OneCraft team. Last checked 13 September 2026.