Inline validation is problematic

Live inline validation informs users whether what they type is valid as they type. The theory is that it's easier to fix errors as soon as they occur instead of waiting until submission.

But in reality, inline validation createa a number of usability issues, that are best avoided. Here I'll explain what the problems are and offer some better ways of helping users fix errors in forms.

1. Interruption causes friction

For fields thats require a certain number of characters, the first keystroke will cause an error. Meaning users will be interrupted immediately and frequently thereafter.

The first keystroke causes an unnecessary interruption.

We could validate only when the user has entered enough characters but this means the user will only get feedback after completing the field successfully which is pointless.

2. Validating when the user leaves the field is too late

We could show feedback when the user leaves (blurs) the field but this is too late because the user has moved to the next field and maybe even started to fill it out. Showing feedback at this point stops interrupts them again.

Some users switch windows by using a password manager, for example. Switching windows triggers the blur even which causes the validation routine to prematurely run before the user finishes filling in the field.

Leaving the field causes errors to show prematurely.

Also, tabbing to the next field will cause an error to be shown on the first field. This would probably make the user leave the second field to go and fix the first field. But this would then cause an error in the second field.

3. Visual glitches are disorientating

As fields switch back and forth between valid and invalid states, the error will appear and disappear. This causes the page to jump which can be very disorientating and cause users to make mistakes.

State changes cause the page to judder.

Ideally, errors should be hidden as the user starts fixing an erroneous field but this makes this particular problem even worse.

4. Grouped fields behave inconsistently

Groups of fields need to be considered holistically when validating.

For example, we may have checkboxes that need at least two to be selected to be valid. But if the user clicks one and blurs the field is that an error?

The same goes for a date input (shown below). If the user enters a valid day and moves to the month field the entire field becomes invalid.

We could validate when the last field is blurred, but what if someone has focused the day field, left it blank and moved to the month field?

An interface that is designed to rely on a user doing something in a particular order is fragile and should be avoided.

Alternatively, we could validate this particular field when the user submits, but this could give users a false impression that they've entered everything correclty when they haven't.

Not to mention this approach would be inconsistent with the rest of the form.

5. Some fields need to be validated on the server when the form is submitted

Some validation rules, like checking someone's login credentials, can only be performed on the server when submitted. This makes the experience inconsistent.

6. False positives are untrustworthy

Some implementations use inline validation to show green ticks when the user fills out a field successfully. This may provide a sense of progression and stop people feeling like they need to check through their answers later on.

However, inline validation typically checks the format. This means that a correctly formatted field may still be erroneous once it's submitted. This not makes the experience untrustworthy and unpleasant.

7. Pre-populated fields are tricky

Pre-populated fields cause further issue. Should we display them in the success state, if there is one? If they appear to have been validated already, should we then hide the success message until they have left the field again?

8. Validation inconsistency

Some fields can be validated as the user types. For example, if typing a letter in a numerical field. But this causes inconsistency and is rarely applicable to the slew of fields requiring various different validation routines.

9. Users might not notice it

Many users look at the keyboard as opposed to their screen when typing. In this case users won't see the error until later or at all.

10. It forces users to switch contexts

Apart from interruption, inline validation causes users to frequently switch between filling in a form and fixing mistakes modes. This is a cognitive burden on the user.

11. Marking success is confusing

Luke Wobrelski's testing showed that users weren't sure how to interpret a green tick. He says the participants knew we had no way to know their correct name, so they knew that the green check mark didn’t mean “correct.” But they weren’t sure and that was the problem.

12. Problems for screen reader users

When someone is using a screen reader they may want to go through the form fields to get a feel for what is coming before attempting to fill each field out. This could cause errors in all fields before the user even started their journey.


Inline validation causes many problems and forces users to switch between filling in forms and fixing them.

Designers like inline validation because it avoids users seeing lots of errors after filling a long form. Assuming this is a true we can solve this by:

  • Removing unnecessary fields
  • Ensuring fields are well-understood with clear guidance
  • Using One Thing Per Page

In any case, designing the perfect inline validation experience is nigh on impossible. Any potential benefit is outweighed by the problems it introduces.