If a user creation page has a field where you are asked to re-enter your password, when should the page validate that the second password matches the first?

I do not have control over whether or not we include the password confirmation. I am only able to request a change to when we show a validation error.

The answer to a previous post on validating the initial password based on complexity rules suggests showing the error as the password is typed, with a short delay. However, in the case of a repeated password field, we are not checking complexity, only that it matches, so validating that mypass is not the same as mypassword while the user is still typing in the second field seems useless and annoying. (Edited to clarify that my issue is with validation of input that the user already knows is incomplete)

After reading an inline validation article on A List Apart, it sounds like validation after the user has completed the field was most user-friendly. However, the password fields are the last fields on the form, so the next step would be to click "Create", making on-blur validation somewhat more complicated.

At this point, I have two questions:

  1. Should the validation of the second field wait until after the user has finished?
  2. What should be considered "after" in this case, since they are unlikely to make any more changes to the form before attempting to submit? After the user has not typed anything for a second? After they click "Create"? After they have typed the same number of characters as the first password?
  • 2
    My 2c: Validate 1s or 0.5s after user stops typing, disable submit button until correct validation is indicated.
    – user56701
    Commented Nov 12, 2014 at 8:43

5 Answers 5


To answer your question directly, validation shouldn't wait for the user to be done, so much as it should wait to make logical sense.

As guessed in the second part of your question, the passwords cannot logically match unless they are the same length, so waiting to validate after they are the same length, and doing so immediately, gives the user a chance to enter the password a second time without being unnecessarily obtrusive.

How you choose to then indicate that there is a discrepancy between the two fields is up to your best judgement.


Too bad you cannot remove the confirm password field. The method that forms guru Luke Wroblewski recommends is to simply show the password rather than masking it in the first place. Since you don't make that call, the validation should happen on focus out event of the confirm password field.

  • Even if the on focus out event is likely going to be clicking on the Submit button?
    – AlannaRose
    Commented Nov 11, 2014 at 23:08
  • showing the password is a security concern, for shoulder surfers, that's why the password is masked in the first place
    – ThaSaleni
    Commented Nov 13, 2014 at 13:27
  • Focusout/blur event will still be triggered if the next action is the click of the Submit button. All of this is assuming you are planning on using client-side form validation, and not server-side form validation. If you know your audience will be running a modern browser, you can try the HTML5 constraint validation techniques as referenced here: html5rocks.com/en/tutorials/forms/constraintvalidation
    – thomasyung
    Commented Nov 13, 2014 at 14:58
  • A better example of constraint validation is sitepoint.com/html5-forms-javascript-constraint-validation-api ... Warning. If you still have to support IE9 or less, then you need to do a lot of workarounds.
    – thomasyung
    Commented Nov 13, 2014 at 15:10
  • See this for explanation of how Luke W. solved this problem elegantly: lukew.com/ff/entry.asp?1653
    – thomasyung
    Commented Nov 14, 2014 at 14:34

I don't agree with what you say about checking for the repeated password being useless and annoying. This would be a different type of validation and therefore it would require different action from the user (re-type the password again)

And I don't understand why since this is the last field in the form makes it more complicated.

I would go with what the very good article you found suggests, that us to make the validation happening as soon as the user finishes typing the repeated password.

  • To clarify, I'm saying that checking that the passwords match before they have finished typing is annoying, not that checking at all is annoying. If I haven't finished typing yet, I know my passwords don't match: why are you telling me?
    – AlannaRose
    Commented Nov 11, 2014 at 21:21
  • To answer your other question: since this is the last field, there is no action the user is likely to take to clearly indicate focus has changed other than clicking on the submit button. Normally, checking for a click or tab to another field ("on blur") is a good way to tell that the user is finished. In the article, for example, they say "after the user indicated that she was done answering a question by moving on to the next one."
    – AlannaRose
    Commented Nov 11, 2014 at 21:24
  • Sorry, I get what you mean now. Is there a reason why the validation of the email is position at the end of the form? Is the user required to approve any Terms and Condition by any chance?
    – Taritaro
    Commented Nov 11, 2014 at 21:29
  • 2
    FYI: I just tried this scenario on Twitter and his is what I came-up with: youtu.be/wg6aWZcQfIc As you can see they seems to perform a real-time validation (not great as you said but it doesn't really bother me). What do bother me is that they don't tell when the password s are matching. I hope that helps. Antonio
    – Taritaro
    Commented Nov 11, 2014 at 21:39
  • The reason the password field is last is because that's a common location for it --- maybe I'll see if we can rearrange the order. And thanks, it's useful to know that a big web company decided it was OK to use real-time validation for this. I personally find it annoying and distracting, but I'm trying to gauge if I am over-reacting to the annoyance of the message.
    – AlannaRose
    Commented Nov 11, 2014 at 23:05

I think you should have the validation happen as they type.

I agree with you that it is a little annoying as a user ("I know it doesn't match, I haven't finished yet!") but because its the last field before the submit button, it seems to the best choice for a bad situation.

Of course as Taritaro pointed out, if the password is correct do let them know :)


If possible, get rid of the confirmation.*

If not, you have to validate after the user has provided the confirmation password.

Up until this point showing a validation error message to the user is an insult as they have not told you that they are finished yet.

Keep in mind that 95% of the time the user will re-type their password correctly and never see the message so showing it only on form submission should be fine.

*research has shown that the password confirmation field causes more problems than it's worth. With a move towards mobile/touchscreen typing passwords is terrible usability having to flip through 2-3 keyboards... forcing the user to do it twice is torture... and often the reason why they fail to match because they are hasty in the second field causing a validation error that is redundant because they typed it correctly in the first box!

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.