Bad validation messages make users feel wrong and give them no way out: “Invalid input,” a red field, no explanation. Good validation quietly guides people to a correct answer. This article covers when to validate, where to put the message, and how to word it so a form feels like a helpful assistant rather than a strict gatekeeper.
Why timing is the hardest part
Most validation problems are timing problems, not wording problems. There are three moments you can validate, and each has a cost:
- On every keystroke – fast feedback, but it flags an email as invalid while the user is still typing it, which feels like nagging.
- On blur (when the field loses focus) – the field is complete, so an error is fair and expected. This is usually the best default.
- On submit – honest but late; the user has to scroll back and fix several fields at once.
A practical rule works well in real projects: validate a field on blur for the first time, then switch that field to live validation only after it has already shown an error. This way you never interrupt a first attempt, but you confirm the fix instantly once the user knows something is wrong.
Where the message belongs
Put the error message directly beside or below the field it refers to, not in a summary box at the top that forces the eye to travel. Inline messages keep the problem and the fix in the same place. A top-of-form summary is still useful for long forms and for screen-reader users, but it should supplement inline messages, not replace them.
Color is not enough
Red borders alone fail anyone who cannot distinguish the color and fail everyone when several fields turn red at once. Pair color with text and, ideally, an icon. The message carries the meaning; the color only draws attention.
How to word the message
A useful error message answers two questions: what went wrong, and what to do about it. “Invalid password” answers neither. “Password needs at least 8 characters” answers both. Follow three habits:
- Name the specific rule that failed, not a generic “invalid.”
- State the fix in plain language, ideally showing the accepted format.
- Avoid blame words. “You entered” and “illegal” put fault on the user. Describe the field’s need instead.
A real scenario
A signup form asks for a phone number. The user types spaces and dashes out of habit. On submit, the field turns red with “Invalid.” The user has no idea whether the problem is the dashes, the length, or the country code, so they guess and fail again. The fix has two parts. First, accept the input the user naturally provides by stripping spaces and dashes before validating. Second, if it still fails, say “Enter a 10-digit number, for example 5551234567.” The example does more teaching than any rule description. Often the best validation is being more forgiving about input so fewer errors happen at all.
Common mistakes and how to fix them
- Validating on every keystroke from the start. Fix: wait for blur on the first pass.
- Clearing the user’s input after an error. Fix: never wipe fields; people should edit, not retype.
- Generic “invalid” text. Fix: name the rule and show the accepted format.
- Rejecting formatting the user finds natural. Fix: normalize spaces, dashes, and capitalization before you judge the value.
- Only using color to signal errors. Fix: add text and connect the message to the field for assistive technology.
- Disabling the submit button silently. Fix: a greyed-out button with no reason leaves users stuck; let them submit and then explain what needs fixing.
Action steps checklist
- Default to validating each field on blur, not per keystroke.
- Switch a field to live validation only after it has errored once.
- Place messages inline, next to the relevant field.
- Write each message as: what failed plus how to fix it, with an example.
- Normalize common formatting before validating.
- Never clear a field on error.
- Signal errors with text and icon, not color alone.
Conclusion and next step
Validation is a conversation, not a verdict. Pick your most-used form, rewrite each error to name the rule and show the fix, and change the timing to on-blur. Users will finish faster and abandon less.
FAQ
Should the submit button be disabled until the form is valid?
Usually not. A disabled button gives no reason and traps users who cannot see what is missing. Let people submit, then show clear inline errors. Reserve disabling for cases where the reason is already obvious on screen.
Is inline validation always better than validating on submit?
Inline is better for most fields because it catches problems early and close to the source. Some checks, like server-side uniqueness of a username, can only happen on submit or on blur with a request, so a mix is normal.
How do I handle password rules?
Show the requirements before the user types, then check them off as each is met. This turns hidden rules into a visible target and removes the guesswork that causes repeated failures.
What tone should error messages use?
Neutral and helpful. Describe what the field needs rather than what the user did wrong. Avoid exclamation marks and words like “illegal” or “forbidden,” which read as scolding.
References
The Web Content Accessibility Guidelines (WCAG) from the W3C cover error identification and the requirement not to rely on color alone; they are a genuine, widely used standard worth consulting for accessible form validation.