Inline validation is problematic

Live inline validation tells users whether what they type is valid as they type.

Theoritically it's easier to fix errors as they occur instead of waiting until after form submission.

But inline validation is problematic for many reasons.

In this article I'll explain all the problems this causes and what to do instead.

1. It interrupts users too early and too often

For fields thats require a certain number of characters, the first keystroke constitutes an error. This means users are interrupted immediately and frequently thereafter.

As soon as the user types, an error will be displayed before the user has answered the question.

We could validate the field when the user enters enough characters, but this only provides feedback when the field has been completed which is pointless.

2. Validating after the user leaves the field onblur is too late

Providing feedback onblur is too late because the user is concentrating on answering the next question. Showing an error in the previous field at this point draws the user away from the task at hand.

Blurring the field causes errors to show prematurely.

Some people user a password manager. Opening the password manager, fires the blur event which cases the validation to run before the user answers the question.

Worse still, tabbing to the next field causes an error in the first field. When the user tabs to go back to the first field, the second field will spwan an error too.

3. It causes the page to jump

As the state of the field switch between valid and invalid, errors will appear and disappear respectively.

This results in a page jump which can be disorientating and cause users to make mistakes.

The page jumps as the field switches between invalid and valid.

4. It can't be applied consistently to grouped inputs

Fields that are made up of multiple inputs need to be validated together.

A checkbox group can't be validated in the same way.

For example, a checkbox group could require at least 1 to be selected. In this case, should an error be shown when the user tabs passwed 1 checkbox to get to another?

I'd say no. In which case, when should validation happen?

A date field made up of inputs for day, monnth and year is also a challenge.

If the user types a valid day and tabs to the month input, should we show an error?

We could validate the field when the users blurs the year input, but what if the user leaves the day input empty and tabs to the month input—should this show an error?

A solution that relies on users doing things in a specific order is fragile.

We could just validate fields like this on submit, but this provides an inconsistent and confusing experience for people who have now come to expect questions to be validated as they go.

5. Some questions need to be validated on the server regardless

Some questions, like login credentials, can only be validated on the server.

Having some questions validated as the user types and some questions on submit creates additional inconsistency.

6. False positives create an untrustworthy experience

Some implementations of live validation show users a green check for a valid answer. This can give users a sense of progression and stop users needing to check their answers later.

But live validation only checks the format which means that a correctly formatted field may still be invalid once the it's submitted.

This is confusing, unpleasant and untrustworthy as Luke Wroblewski's explains:

‘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.’

7. It's difficult to handle pre-populated fields

Pre-populated fields are challenging—should we show them in the success state? If they appear to have been validated already, should we hide the success message until they have left the field again?

8. It can't be applied consistently across different types of question

Some errors can be caught as the user types, like typing a letter in an numerical input. But other types of errors can't be caught until the entire answer has been entered. Applying different interactions is inconsistent.

9. Some people might not notice the feedback

Many users do not look at the screens as they type, so there's a chance they won't notice the error.

10. It forces users to switch modes

Live inline validation causes users to constantly switch between answering questions and fixing mistakes. This is a cognitive burden on the user.

11. It can be problematic for screen reader users

Some screen reader users explore all the fields in a form before they use it. This lets them know what's coming ahead of time.

Live inline validation could cause errors to display in all of the fields before the user has had a chance to type answers.


Inline validation causes many problems and forces users to switch modes repeatedly which is tiring.

In any case, implementing the perfect live inline validation routine is nigh on impossible. Any potential benefit is outweight by the problems it introduces.

Instead, help users to avoid errors by:

  • removing unnecessary questions
  • providing clear label and hint text
  • starting with one thing per page