Login form error messages: which ones mislead

The sign-in page has one red line for every failure, and the line says the email or password was wrong. A visitor who never verified the address is told the password is wrong, so they reset a password that was fine. A locked account gets the same line, so they keep trying, and each try can count toward the lock. A server fault gets the same line too, and the visitor blames their own typing. The owner tests with a working account, so the line never looks wrong to them.

• Sign in with a wrong password, an unknown email, an unverified account and a locked one, and compare the text.
• Check whether the text differs for an unknown email and a wrong password. Identical text is the safe choice.
• Look for a line that names the next step, such as resending the verification email.
• Check that a server error shows a plain sentence, not a code, a stack trace or the word undefined.
• Confirm the message clears when the visitor edits either field.

A login form receives the failure from the server, and the server often knows which case it is. The usual safe rule is to say the same thing for a wrong password and an unknown email, because a different sentence tells a stranger which emails have accounts on your site. An unverified address or a locked account is different. The visitor can act on it, by confirming the address or waiting for the lock to lift, and the message should say which. A server fault needs a plain sentence and a retry, not a code.

Login forms are often built from the signup form, so they carry its checks. A visitor who made a password before a new rule, such as a required symbol, gets a message about that rule when they sign in. The password was accepted at signup and is correct, but the login form checks it against the new rule first and stops. Read the text: if it names a rule that only applies to new passwords, the check belongs on signup, not sign-in. The login should only check that a password was typed and let the server decide whether it matches.

To test the messages, you need an account for each failure: one with a correct password, one that never verified its email, and one that is locked after the attempts your site allows. The unknown email needs no account at all. Give each visitor the account that matches their failure, or have them type a wrong password against a real account. With paid credits, visitors can sign in with a test account you give them, but they cannot use Google or single sign on, so a login that offers only those stops the run at that step.

Each new sign-in rule, such as a lockout after several tries or a verification step for new devices, adds a failure the message may not name. Rerun the same four sign-in attempts after each change, and check that each one still gets its own line. Behind a site password, use the password you give the visitors and check each preview deploy before it goes live.