I have a signup form where I made a REAL-TIME validation when the user starts typing as you see in the picture.

I don't know if this harms the user experience or no, and also I did not find a resource about this kind of validation. enter image description here .

  • 3
    Personally, I disagree with the answers. I like being updated after each keystroke. (But that is just one person's opinion, and not an answer.)
    – Evorlor
    Commented Aug 20, 2020 at 20:49
  • As an aside, I hope you aren't validating for uniqueness with every keystroke. Please do not do that to yourself. It wouldn't be a problem in the early days but that's the sort of thing that, if your application does that in a lot of places, could cause your data back end to grind to a halt, and the cost of your bandwidth could get out of hand. -Sincerely, a back end guy.
    – user81010
    Commented Aug 20, 2020 at 22:38
  • Test it out with a group of users and get their feedback. I am doing the exactly the same thing you are doing to my forms. I am going to do some user testing to see it is is a problem. The irritation I can see, if the validation keeps appearing and disappearing after every keystroke. That can be annoying. Commented Aug 21, 2020 at 0:13
  • Nobody seem to mention input device, keyboard is quite capable, people can type as fast as 100-150 wpm, sometimes meaning your validation can't even keep up, let alone the user gets any productive use out of it. But for phone and touch screen, it is in my opinion that text input is not in a respectable state, even after 20 or so years. The common tactics seem to be to merely avoid any prolonged user input in general, on touch screen devices. However I'm not a ui expert, and following well founded ui rules could be best. Commented Aug 21, 2020 at 9:57
  • 5
    I would like to add that for 90 % of internet users, the error message shown is as cryptic as it gets.
    – chaosflaws
    Commented Aug 21, 2020 at 11:47

8 Answers 8


To quote from nngroup.com:

7. Don’t Validate Fields Before Input is Complete
It can be annoying to see an error message before being given the opportunity to finish typing.

  • 8
    +1, but "Complete" here is underselling how complex it is to know when someone is finished. Most developers go with validating after each keystroke or on blur for simplicity, but those have issues with over and under validating, respectively. The best case involves waiting a short time after a key press (perhaps inversely proportional to the length of input) but it's complicated if done right and a resource drain if done poorly. Commented Aug 20, 2020 at 13:10
  • 3
    @NathanRabe The change event works well for this. developer.mozilla.org/en-US/docs/Web/API/HTMLElement/…
    – Yay295
    Commented Aug 20, 2020 at 15:01
  • @NathanRabe Still, on blur is a good alternative for mobile. Android has a button to jump to the next field. So, you either wait some time and randomly show the message, or put it on a blur. I prefer putting on blur first and then validate while the person is typing (if there was an error). Commented Aug 20, 2020 at 15:01
  • 22
    i find that a good approach is to wait until the field loses focus (blur) to validate for the first time, and then validate per-keystroke after that first validation. that gives the user one full interrupted attempt before being shown an error message, and then live updates while the user makes the needed adjustments to resolve the validation error (since that process is sometimes trial-and-error for the user). Commented Aug 20, 2020 at 15:48
  • 1
    I prefer debouncing the validations.
    – Andy
    Commented Aug 21, 2020 at 7:44

Validation should not start before input is complete

When the user starts entering a correct value, no errors should appear while typing. The input is considered to be complete when

  • the input focus is lost (navigating to another field) or
  • the form is submitted (e.g. autosubmit when pressing enter) or even
  • after not receiving input for some time (e.g. 3sec after the last input event).

Showing input errors immediately while typing is very distracting ("must have at least 3 characters" when starting to type) and rarely helpful.

Validation errors should be removed on the fly

Once the field is validated, and shows some errors, the user wants the error to vanish as soon as the edited value is correct, not when he leaves the field or submits the form (which probably will be disabled anyways as long as there are errors displayed).

This can be achieved by removing all errors from the field when it becomes dirty again (and revalidate it later on submit or focus lost), or automatically revalidating the field every time it is changed.


Rather than continuously display a red validation message when the user has not met a field's requirements, a nice alternative is to (1) display a tip that tells the user what is expected, and (2) display a green "requirements met" message when the user has entered a valid value. You can go green as soon as the input is OK.

  • 1
    This is amazingly sensible advice, and so obvious that I wonder why more people (including myself) don't do it! Commented Aug 22, 2020 at 21:54

It depends on the type of Input Field.

enter image description here

  • For the Email Field:

You don't wanna be too jumpy. Let the user finish typing the email address. If the input field turns red with an error-text at the moment the user starts typing, it will annoy the user.

The right approach would be to let the user finish typing and when the user shifts the focus away from that field, validate and show whether it looks good or throw an exception text if there is any.

  • For the Username & Password Field:

Username and password fields need to be validated pre-submission because they have the strictest input requirements. So clearly show the user what is accepted and what is not in real-time as they start typing.

Link to the Articles:



  • 1
    I don't agree on showing errors all the time, that gives the wrong message. Better show successful entry. As the source I posted states: "Indicate Successful Entry for Complex Fields".
    – jazZRo
    Commented Aug 20, 2020 at 11:51
  • @jazZRo There is a difference between error, exception, and suggestions. The OP was asking about validating an input field, not when to show an error
    – Sooraj MV
    Commented Aug 21, 2020 at 3:08
  • Ok, the image may show validation messages that are technically no errors. But the messages are red and telling what is wrong with the current input, from a user perspective they are perceived as errors. My point is that any input feels more rewarding when this is brought with a more positive design.
    – jazZRo
    Commented Aug 21, 2020 at 15:05
  • Is it good to show errors on the right of fields or it eats more spaces ? Commented Aug 22, 2020 at 13:55

Real-time validation works if you properly handle incomplete responses.

The example given is bad UI because "reara" is a valid way to start an email address. An example where real-time validation can reject an incomplete response is "reara@@". In that case the real-time validation can reject it without waiting for completion.

In general, you need to be show an error message when there is no additional input which can make the response valid. How hard it is to detect this will vary from case to case. If you have a dictionary, it's fairly easy. With regular expressions, less so.

It of course helps to have good error messages, which are appropriate in the context of incomplete input. "An email address should contain exactly one @ sign" for instance.

If you can't handle incomplete responses, for example because it's always possible to enter a suffix to make a particular field legal, then you should wait for complete input as suggested in the other answers.

  • While true for "usual" emails, there is actually the possibility for multiple @-symbols (and oh, so much more) in an email-address (stackoverflow.com/q/12355858/3892515)
    – JFBM
    Commented Aug 21, 2020 at 11:51
  • @J_F_B_M: Still, reara@@ is an invalid prefix. Any @ that's not a separator must be quoted. The error message isn't trying to describe the precise RFC rule, even though that's what the validator should use.
    – MSalters
    Commented Aug 21, 2020 at 12:12
  • It seems I duplicated your answer, somehow I scrolled over this before answering. There are some implementation details in my answer that might prove useful though; if you agree with them and could incorporate them in your answer, we could do away with mine. (There are too many answers to read here already.)
    – Bass
    Commented Aug 22, 2020 at 14:23

I wrote an article about the problem with live validation:

In short: it either provides feedback too early and often before the user has had a chance to type their answer OR it provides it too late once the user is finished typing their answer and is focused on the next field answering the next question.

Instead focus on:

  • clear and concise label, hint text and error messages
  • forgive trivial mistakes
  • let the user submit the form when they’re ready

This way users will very rarely see an error message and when they do, it will be when they expect to see one.

  • I read your article but In [my form] (xux06.csb.app) I did validate when the user leaves the field empty. Only data. Commented Aug 25, 2020 at 2:39
  • Let us know how you get on in user research with it – if you can make sure to test with a diverse set of users. Commented Aug 25, 2020 at 13:13

It is good to validate live. However, such a validation needs to distinguish between two cases:

  1. input that can be made valid by adding stuff at the end, and
  2. input that can not be made valid by adding stuff at the end.

The latter case should pop out the error message instantly, while the former needs to wait until the input is complete.

But how can you tell one from another?

That's a bit tricky given current tools, but if you are writing your own regular expression engine (or some other kind of finite state machine for validation) you can achieve it like this:

  • if the engine reached the end of the regexp (the goal state), there was a match.
  • if the engine reached the end of the string, there might be a match later.
  • if the engine couldn't reach either, there's never going to be a match.

The problem is, most programming languages don't give any indication about reaching the end of the string. Also, even though it's a minor change to any existing regexp engine, rolling your own is pretty much certainly out of scope for every user interface design project ever.


Simple Answer i guess it would be that if its a login page having 3-4 fields its completely fine to add validation when user clicks submit

Long forms the validation check should trigger when the input is on any other field except the mentioned field.

This is doable in Javascript

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.