ui patterns
Inline validation
What is inline validation?
Inline validation checks a form field as the person fills it in - or just after they leave it - and shows the result there and then, rather than waiting for them to submit the whole form. Done well it catches mistakes early, next to the field that caused them, so people fix problems while the context is fresh instead of being bounced back to a wall of errors at the end.
Also known as: inline validation, live validation, field validation
Prefer to watch?
Watch the recap 1:05
The demo
A quick sign-up form. First it only tells you what's wrong after you submit - then it checks each field as you leave it. Put a couple of mistakes in and feel which one is less painful.
What this demo shows (text version)
A short sign-up form is shown two ways. With "on submit only", you fill in every field and only when you press submit do all the errors appear together at the end, away from the fields that caused them, so you have to hunt back through and remember what you typed. With "inline (on blur)", each field is checked the moment you leave it and shows its result right there, so you fix problems immediately while the context is fresh.
That's inline validation: timely, local feedback that catches mistakes at the field instead of in a wall at the end. The key caveat is timing - validate when someone leaves a field, not while they're still typing, or it nags. Keep messages specific and kind, re-check on submit as a backstop, and prevent errors up front where you can.
Validate at the right moment, beside the field, and people fix errors easily; validate everything only on submit, and they hit a frustrating wall. Inline validation's strength is timely, local feedback - an error appears at the field you just left, while you still remember what you typed. But timing is everything: validating while someone is still typing (before they've finished) nags and shows premature errors, so the sweet spot is usually on blur (when they leave the field), with positive confirmation where helpful. Keep messages specific and kind ("Email needs an @"), put them at the field, and combine with a final check on submit. Best of all, prevent errors up front (constraints, input masks, clear formats) so there's less to validate.
Submit-only, every mistake landed at once at the end - far from the fields, after all your effort, demoralising. Inline, each problem surfaced at its own field the moment you moved on, while you still knew what you'd typed, so fixing it was quick. That's the value of validating at the right time and place - and the caveat is timing: do it as people leave a field, not while they're mid-keystroke.
Validating only on submit forces people to complete the whole form blind, then face a batch of errors detached from the fields that caused them - they have to scroll, re-find each field, and reconstruct what went wrong, which is frustrating and a known cause of abandonment. Inline validation moves the feedback next to the field and close in time to the action, so corrections are cheap and the context is still fresh.
Timing is the make-or-break detail. Validating on every keystroke (while-typing) is usually too eager: it flags an email as invalid before the user has finished typing it, which feels like nagging. The reliable default is validating on blur - when the person leaves the field - so they get to finish first; for some cases, validate after a pause, or confirm success live. Re-validate on submit as a backstop, and revalidate a corrected field promptly.
Make the messages specific, polite and actionable, placed at the field and associated with it for screen readers (aria-describedby, live regions). Show positive confirmation where it reassures, don't block typing, and keep error states accessible (not colour-only). Crucially, prefer prevention to validation where possible - input constraints, masks, sensible formats and clear requirements stated up front mean fewer errors to catch in the first place.