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 why it is and what to do instead.

1. It interrupts users

For fields thats require a certain number of characters, the first keystroke will constitute an error. This means users are interrupted too early and too often thereafter.

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

The field could be validated after the user enters enough characters, but this would only provide feedback when validation has passed which is pointless.

2. Validating on blur is too late

Providing feedback when the user leaves a field is too late because they're focused on the next question. Showing an error in the previous field draws the user away from the task at hand.

Blurring the field causes errors to show prematurely.

Some people user a password manager. Leaving the field to open the password manager will trigger the blur event, which causes the validation routine to fire before the user answers the question.

Furthermore, tabbing to the next field causes an error in the previous one. When the user tabs to go back to the first field, the second field will spawn another error.

3. It causes the page to jump

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

This causes the page to 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 fields that are made up of multiple 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 occur?

The same applies to a date field made up of inputs for day, month and year.

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

Again, I'd say no.

The field could be validated when the year input is blurred, but what if the user leaves the day input empty and tabs to the month input—should an error be shown here?

This solution relies on users doing things in a specific order and that makes it prone to error.

We could validate fields like this on submit, but this creates an inconsistent experience for users who now expect questions to be validated one by one.

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

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 is inconsistent.

6. It can cause false positives

Some implementations of live validation show users a green tick for a correct answer.

But live validation can only check the format which means that a correctly formatted field may still be invalid once submitted.

This is 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

Should pre-populated fields be shown in the success state? If they appear to have been validated already, should the success state be hidden until the user leaves the field again?

8. It can't be applied consistently for different validation rules

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.

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

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.

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


Inline validation causes problems and forces users to switch mental 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