Form error messages: the UX that saves conversions
Published on 29 July 2026 · 8 min read
A visitor who triggers a form error is your best prospect: they read the page, decided to act, started filling in. Losing them at this step — because an error message is unfindable, incomprehensible, or blaming — is the most infuriating leak on a landing page. The question isn't just cosmetic: the very moment the error appears changes performance. In an experimental study published in Interacting with Computers, Javier Bargas-Avila and his colleagues at the University of Basel compared six ways of presenting web form errors and found that errors shown during typing (aggressive immediate validation) degrade performance: users barely notice them or interrupt their input, whereas errors presented at form submission are handled better (Bargas-Avila et al., 2007). From that result and from practice follows a simple doctrine, in four decisions.
Decision 1 — When: on leaving the field, not while typing
The worst timing is validation on every keystroke: the email gets declared invalid from the very first letter of "jean@…", punishing the user for input they haven't finished. The best current compromise: validate a field when the user leaves it (on blur), and make the error disappear as soon as the correction resolves it. Validation only at submission remains acceptable for a short form, but forces users to re-scan the form to find the offending fields — painful beyond three fields, which is already too many according to our article on the number of form fields.
Decision 2 — Where: next to the field, never elsewhere
The error appears immediately below (or beside) the field concerned, which also receives a visual marker (border, icon). Anti-patterns to ban: an error summary only at the top of the page (the user has to make the connection themselves), the blocking JavaScript alert, and the error at the bottom of the form on mobile — off-screen at the moment it appears. On mobile precisely, where the keyboard hides half the page, the field-adjacent error is the only one that stays visible; our guide to landing page forms covers the other mobile specifics.
Decision 3 — What: say how to fix it, not just that it's wrong
"Invalid field" helps no one. A good error message carries three pieces of information: what's wrong, why, and how to fix it. Microcopy does all the work here:
- Vague: "Invalid email." → Useful: "This email looks incomplete — the @ or the domain is missing (e.g. name@company.com)."
- Technical: "The tel field format does not match the expected pattern." → Human: "Enter a 10-digit number, for example 06 12 34 56 78."
- Blaming: "You filled in this field incorrectly." → Neutral: "This field only accepts digits."
Tone matters: an error is a friction moment, not the place for forced humor or reproach. Stay neutral, precise, solution-oriented.
Decision 4 — How: visible without relying on color alone
Red alone isn't enough: about 8% of men perceive red/green contrasts poorly. Combine color, icon, and text — an accessibility requirement that benefits everyone. Add ARIA attributes (aria-invalid, aria-describedby pointing to the message) so screen readers announce the error, and never empty already-filled fields after an error: redoing lost input is the friction that makes people quit.
Better than a good message: no error at all
The best error is the one you prevent. Flexible formats (accepting "06 12 34 56 78" as well as "0612345678"), examples in labels, address autocompletion, fields matched to the mobile keyboard (type="email", inputmode="numeric"): every constraint relaxed in code is an error the user will never see. It's the same spirit as hunting down captcha friction — and if your form is long, splitting it into multiple steps lets you validate in small blocks rather than one big volley of errors.
Finally, measure: an abnormal abandonment rate between input start and submission, visible in GA4 with the right events, almost always points to a problematic field or validation. The forms in our LanderKit templates (€89 each, €229 for the pack) apply these rules out of the box — validation on blur, adjacent and explicit messages, fields never emptied — as the Real Estate template demo shows with its two-step estimation form.
FAQ
Frequently asked questions
Should fields be validated while typing?
No — research shows that errors displayed during input are handled poorly: they interrupt or go unnoticed. Validate when the user leaves the field (blur) and clear the error as soon as it's fixed. The one useful exception: live positive confirmation for fields with known rules, like password strength.
Where should the error message go?
Directly below or beside the field concerned, with a visual marker on the field itself. A summary at the top of the page can be added for long forms, but should never replace the adjacent error — especially on mobile, where the top of the page is off-screen during input.
How should a good error message be worded?
Three elements: what's wrong, why, and how to fix it — with an example if possible. "This email looks incomplete (e.g. name@company.com)" rather than "Invalid email". Neutral, solution-oriented tone: never reproach, no technical jargon.
Do form errors really lose conversions?
Yes, and the most expensive ones: a visitor who triggers an error had already decided to convert. An abandonment spike between input start and submission in your analytics almost always signals over-strict validation, an unfindable message, or fields emptied after an error.
Read next
Related articles
- Real-time form validation: when to correct the user (and when to stay quiet)An email without an @ flagged the moment the user leaves the field: that's real-time validation done right. The same message flashing red from the second letter typed: that's how you turn a form into an ordeal. The difference is timing — and it has been measured.
- Form microcopy: the small words that change completion ratesTwo forms can have the same number of fields, the same layout, and very different completion rates. What separates them often comes down to a few words: how a field is labelled, how help text is phrased, how an error is announced.
- Passkeys (WebAuthn) on a SaaS signup form: should you drop the password?A "password" field with its eight-character minimum, its uppercase letter and its special character remains one of the most well-documented friction points on a SaaS signup form. The passkey — a fingerprint, a face, or a device unlock code, with nothing to remember — promises to remove it outright. The research on real-world WebAuthn adoption tells a more nuanced story than the marketing pitch: what works, what fails quietly, and how to decide for your SaaS landing page.