Real-time form validation: when to correct the user (and when to stay quiet)

On a landing page form, there are two ways to flag an error: at the very end, when the user clicks “Submit” and discovers a list of red fields; or as they type, field by field. The second — real-time or inline validation — reduces back-and-forth and abandonment, but only if it fires at the right moment. Badly tuned, it shouts “error” at someone who hasn't finished writing, and degrades the experience instead of improving it. This guide sets the timing rules, as a companion to our article on writing error messages.

What research measured about error timing

The “when” question was studied experimentally by Javier Bargas-Avila's team at the University of Basel, in a study with an explicit title published in Interacting with Computers in 2007: “Usable Error Message Presentation in the World Wide Web: Do Not Show Errors Right Away”. Participants filled in forms whose errors were flagged either immediately while typing, or upon validating the field or the form. The result: showing the error during input degrades performance — users interrupt themselves, correct in a panic or ignore a message shown too early, and end up making more errors. The authors' conclusion became a golden rule of form UX: flag the error once input in the field is finished, not during.

The three timing rules that follow

• Validate on leaving the field (blur), not on keystroke — a user typing “jane.do” hasn't made an error yet, they haven't finished. The verdict comes when they move to the next field.
• Reward early, punish late — the green check can appear as soon as the field becomes valid, even while typing: positive confirmation doesn't interrupt. Only the error message must wait for the end of input.
• Re-validate instantly during correction — once a field has been marked as invalid, the rule flips: the user corrects while looking at the message, and it must disappear as soon as the input becomes valid, not at the next blur. Staying “in error” right after fixing it is one of the sharpest frustrations a form can produce.

What to validate in real time — and what not to

Inline validation shines on fields with verifiable formats: email (presence and position of the @), phone (digit count), postal code, company registration number, password with displayed constraints. It's useless, even counter-productive, on free-text fields: validating a first name or a message in real time adds nothing and multiplies false positives (short names, accented characters, hyphenated names). As for server-side checks — email already registered, valid promo code — they can fire on blur with a discreet loading indicator, but must never block input in the following fields while they run.

The anatomy of a good inline flag

• Under the relevant field, not in a banner at the top of the form: the eye is already on the field.
• Colour + icon + text — never colour alone, to remain readable for colour-blind users and compliant with the criteria in our accessibility guide.
• A message that says how to fix it — “The @ is missing (e.g. name@domain.com)” rather than “Invalid email”, as detailed in our article on microcopy.
• The field keeps the input — emptying an invalid field to “start fresh” is a punishment, never a help.

The conversion effect: why it's worth implementing

The scenario inline validation eliminates is the most destructive in the whole journey: the user fills everything in, clicks “Submit”, and watches the form come back with three red fields — sometimes with the password fields emptied. That's the exact moment where a large share of form abandonment happens: the correction effort arrives after the user has mentally marked the task as done. By flagging problems field by field, as they occur, inline validation spreads that correction cost into painless micro-efforts. On a multi-step form, it becomes indispensable: discovering at step 4 an error made at step 1 guarantees abandonment.

The forms in LanderKit templates (€89 each, €229 for the 10-template bundle) apply this behaviour by default: validation on blur, re-validation on keystroke during correction, messages under the fields with a format example. If you're auditing an existing form, the test is simple: type a deliberately wrong email address, and watch when the message appears, what it says, and when it disappears. Those three moments summarise everything this article just detailed — and they can be fixed in a few lines of code, one of the best effort-to-impact ratios in form optimisation.