I just signed up for a new online service, and when I typed my email address, from the moment I started typing until I had typed the second letter after of the TLD, next to the input field there was an aggressive red error message - "This is not a valid email address".

This message was factually correct. At the same time, I received an error message while I had not actually made an error: I needed to input all those letters etc. in order to get to a valid email address.

I like the idea of validating while still in the field, since this is a pattern that works independently of where the field is in a form. Validating on switching to the next form field cannot work if it's the last in the form - in that case you can only do the validate + error message after hitting submit or a like action.

What is a better way of handling such validity checking while the focus is still in the field/during input? E.g. do you start when the user stops typing - immediately or after a short timeout?

  • 1
    Good question. I too find this annoying because in a way, the message is not even factually correct -- not in the way that matters to the user, because to me the email being validated is the one in my head, and it's beside the point that I haven't finished typing it yet. Heck, why not have the error message say "you're typing too slow"? As for fixes, I think a timeout is a good idea. Commented Jun 25, 2021 at 0:44
  • 1
    Presumably, the field is required. Instead of "neutral" while empty, "red/error" while typing and "green/ok" when finished, it might be better to have "yellow/warning" when empty or incomplete and "green/ok" when okay. Any actual error with explanation(!) (TLD too short, only one address please, missing @, illegal character, ...) might be more appropriate only when the field loses focus Commented Jun 25, 2021 at 5:55
  • 1
    This question/answer should help - ux.stackexchange.com/questions/74531/…
    – Amit Jain
    Commented Jun 25, 2021 at 12:21

4 Answers 4



  1. Validate When Form is Submitted
  2. Validate When Input Loses Focus
  3. Validate X Time after User Stops Typing
  4. Validate After Every Keystroke

Traditionally, sites would use option 1. Option 2 became much more common with the widespread adoption of HTML5. Over the last decade, sites have begun moving to option 4. What I rarely see is option 3, which is a pity because it's the best option, in my opinion.


On forms I write, I typically use Option 3. I wait for the user to stop typing for one second, and then apply validation rules. It's a hybrid approach, which doesn't attack the user with an error before the stop typing, but also gives feedback without having to leave the input.

  • The various options presented aren't all mutually exclusive. Option 1 must be done by the server regardless because you should never trust the client. Options 1, 2, and 3 could be combined (validate after a period of inactivity, when the input loses focus, or when the form is submitted, whichever comes first).
    – jamesdlin
    Commented Jan 12, 2022 at 22:18

The answer from @AndyMercer is a good one, but I'd suggest there is a slightly better approach that combines Option 2 and Option 4.

How I would approach this is using the following steps:

  • The first time the field is focussed, defer validation until the field loses focus/is blurred.
    • This avoids the angry error message before you've had a chance to at least input your response
  • After blur or submit, validate the field and provide your messages.
    • Blur is useful here because if the form has many fields, it provides the error as close to the entry as possible and allows a user to correct it before moving on
    • On submit is often needed as well, because it's feasible the user submits without blurring
  • If the field has been validated at least once (through the methods above), change the validation to happen on keypress, this allows the user to see 'live' validation results as they correct an entry, rather than persisting the messages until blurred/submitted again.

This approach can be more complex to achieve technically, but I believe offers the best experience in terms of avoiding validation messages too early, or leaving them visible when in fact the requirements have been met.


Strictly speaking you describe not email validation but email format validation. Most likely your system will validate email exchanging email messages with user, etc.

If we are talking about email address format so the better solution is to use the same way as you use in the current application to validate zip code format, credit card number format, and so on. Thus you'll have consistent behavior for all components in your current form.


We in our just-in-time validator service for input forms validate all fields on blur, thus, when you leave the field. That does avoid the situation when you get an annoying error just as you start typing. It includes the e-mail field as well. I think of this as a good, balanced way of validating. This also means the fields behave consistently.

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.