Designers spend hours on the visual design of error messages — the red border, the icon, the copy. They spend almost no time on the question that determines whether those messages help or infuriate: when do they appear?
Validation timing is one of the most researched interaction design questions and one of the most consistently mishandled in production. The default in most design systems is “inline validation” — show errors as the user interacts with each field. This feels correct. It is often wrong.
On keystroke (real-time)— errors appear as the user types. This is the most aggressive timing and the most frequently misused. The problem: you can’t know when someone has finished typing until they stop. Someone entering an email address will trigger a “not a valid email” error after typing their name but before typing the @ symbol. They haven’t made an error — they’re just not done yet. Inline validation forces users to switch from completion mode to revision mode constantly, splitting focus, increasing cognitive load, and causing more errors [3].
Real-time validation has one legitimate use case: fields where the constraint is visible as you type and where partial progress is genuinely useful. Password strength meters are the canonical example — the constraint benefits from progressive feedback. For most other fields, real-time validation is noise.
On blur— errors appear when the user leaves the field. This is the most widely recommended timing and a significant improvement over real-time validation for most fields. The user has explicitly moved on, signaling they believe their input is done. On-blur validation strikes the best balance — users get instant feedback without keystroke interruptions, making it ideal for email format checks or phone number formatting [5].
The caveat: on-blur assumes linear progression through fields. Users who jump around, copy-paste, or return to earlier fields can still be caught by premature blur events. And on-blur doesn’t help with fields the user skipped entirely — those need on-submit to catch them.
On submit— errors appear after the user clicks submit. Maligned as “old-fashioned” but genuinely appropriate for shorter forms and low-stakes inputs. The user has a single moment of interruption rather than a running commentary throughout. With submit-only validation, users have full control over when their input is validated [4]. The real cost is error recovery on long multi-section forms: scroll back, find which fields failed, fix them, resubmit.
Hybrid— on blur for individual fields, on submit as a final catch. Fields aren’t prematurely validated, error messages are removed as soon as input is corrected, and positive inline validation confirms progress as users move through a form [2]. This is Baymard Institute’s recommendation based on large-scale usability testing, and the pattern most major systems have converged on.
Vitaly Friedman named the underlying principle cleanly: “reward early, validate late” [1]. Show success signals as soon as a field is clearly correct. Delay error signals until the user has had a reasonable opportunity to finish their input.
The asymmetry matters because the two signals serve different purposes. A green checkmark confirms progress and builds confidence — it’s welcome at almost any point. An error message interrupts a task and demands cognitive attention — it’s only welcome when the user is ready to switch from entering to correcting. Most form validation systems treat both signals identically. They shouldn’t.
One thing most design systems get wrong: error messages appear and then stay — even after the user has corrected the field. The field turns green but the error text lingers for an extra render cycle or simply never clears.
This is a small thing that feels like a large thing in use. The message contradicts the visual state and creates genuine confusion about whether the correction worked. Error messages must clear the instant the error is resolved — not on the next field action, not on submit, immediately.
If your design system documents validation timing at all, make sure it documents clearing timing too. They’re the same problem.
References