Inline Validation
Checking a field as it is filled, so errors surface next to the thing that caused them.
The problem it solves
Validating only on submit makes someone finish a whole form before learning the second field was wrong. The fix is feedback beside the field, timed so it helps rather than nags.
Timing is the entire pattern. Validate too early and you tell someone their email is invalid while they are still typing the first letter. Validate too late and they have moved on. The working rule is to check on blur for a field being filled for the first time, then switch to checking on every keystroke once that field is in an error state, so the error clears the moment it is fixed.
- 1On first entry, say nothing. The field is not wrong yet; it is unfinished.
- 2On blur, validate and show the result beneath the field.
- 3Once a field shows an error, revalidate on input so the correction is acknowledged immediately.
- 4On submit, revalidate everything server-side, move focus to the first error, and summarise the count at the top.
- 5Never clear entered values on failure, including passwords and card numbers.
Say what is wrong and what to do about it, in that order, using the user's words. A message that only restates the rule leaves the person to work out which part of what they typed broke it.
Validation copy that blames
- Invalid input
- Password does not meet requirements
- Please enter a valid email address
- Field is required
- Phone number format is incorrect
- Username unavailable
Validation copy that fixes
- Card numbers are 16 digits. You have entered 15
- Add one number or symbol. Your password needs 8 characters and has 8
- This is missing an @. Did you mean [email protected]?
- Enter the name on the account so we can match your payment
- Include the area code, like 020 7946 0018
- sam is taken. sam-h and sam2026 are free
Success states deserve restraint. A green tick on every completed field turns the form into a scoreboard and adds visual noise. Reserve positive confirmation for fields where the check was genuinely uncertain, such as a username lookup or an address verification.
Accessibility is not optional here. Tie the message to the input with a described-by relationship, mark the field invalid so assistive technology announces it, and never rely on colour alone to signal the state. A red border with no text is invisible to a large number of people.
Worked example
A hypothetical password meter
A signup field shows requirements as a checklist that ticks off live: length, a number, a symbol. Nothing turns red until the person leaves the field. The checklist gives them a target while typing rather than a verdict afterwards, and it removes the guessing that makes password fields the most abandoned input on most signup forms.
When it fits
- Fields have rules the user cannot see, such as length, format, or uniqueness.
- Validation can run fast enough to feel immediate, including any server lookup.
- The form is long enough that finding the error after submit would be expensive.
- The rules can be stated in one short sentence per field.
When it backfires
- Validation fires on every keystroke from the first character, so the field is scolding someone who is halfway through a word.
- The error text restates the rule without pointing at what the user typed.
- The error clears only on resubmit, so a corrected field still looks broken.
- Colour alone carries the state, which fails for anyone who cannot distinguish it.
Products using it
Stripe Checkout
Validates card fields on blur and clears errors as the value is corrected, without wiping the entered digits.
GOV.UK
Pairs inline field errors with an error summary at the top of the page that links to each failing field.
1Password
Shows password rules as a live checklist during creation rather than as a rejection after submission.
The psychology under it
The takeaway
Validate on blur, revalidate on input once a field has failed, and write messages that name the fix.
Finished the teardown? Bank it and the day counts toward your run.