How to Write Form Validation Error Messages

A person enters an email address, moves to the next field, and sees a useful correction. Another person sees almost the same sentence while still typing and wonders what they did wrong. The words may be identical. The experience is not.

That is what makes form validation error messages surprisingly difficult to design. A warmer sentence cannot rescue an impatient trigger, and a precise explanation cannot help if it points to the wrong answer. The real work is deciding what the system knows, when it should speak, and what the person can do next.

There is good evidence to borrow from, but it does not all point to one universal pattern. Ecommerce research, government service guidance, and registration-form experiments place different weight on interruption and early feedback. Understanding that difference is more useful than collecting a list of supposedly perfect error messages.

What real users tell us about validation

In Edward Scott’s January 2024 report on Baymard’s inline validation testing, a participant at L.L.Bean omitted the @ sign in an email address. Feedback appeared after she moved to the next field, and she corrected it within seconds. At Etsy, another participant encountered an error on entering an untouched address field and felt the interface was reprimanding him before he had answered. REI provided a different recovery example: a card-security-code error disappeared when the participant supplied the missing third digit.

These historical observations show why “uses inline validation” is an incomplete description. The moment a message appears, and the moment it goes away, can matter as much as its wording.

For our own form reviews, I would turn these observations into a question: does the message respond to an action the person believes they have finished? Clicking Continue clearly expresses that intention. Leaving a field sometimes does. Placing a cursor in an empty field usually does not. The interface needs a reason to interrupt, not merely a value that currently fails a rule.

A useful counterexample comes from Luke Wroblewski and Etre’s 2009 registration-form study. Twenty-two participants tried six variants. Compared with the control, the best inline-validation version produced a reported 22% increase in success rates and 42% decrease in completion time. One participant said, “You’d rather know about your mistakes as you go along.” Yet green checks beside familiar answers also caused confusion about what the system had actually verified.

The study’s most useful lesson is about uncertainty: a person choosing an available username needs information the system holds; a person typing their own name may not need reassurance from it. I would prioritize feedback where it resolves an unknown, rather than distribute approval symbols evenly across a form.

Why GOV.UK makes a different timing choice

The GOV.UK validation pattern recommends waiting until a person tries to continue or submit, rather than validating when they leave a field. It also advises preserving entered answers, placing an error summary at the top, moving focus to that summary, and identifying errors beside the relevant fields. Earlier validation needs supporting user research.

The difference from the ecommerce examples is worth keeping visible. A short step with one question makes a submission-based correction relatively local: the answer is still in front of you. A long checkout can leave the incorrect field far behind by the time someone submits.

If I were reviewing a workshop booking flow, I would start with the shape of the task. On a single-question date page, Continue is a reasonable point to explain an unavailable selection. On a page containing contact details, accessibility requirements, seat counts, and billing information, waiting until the bottom can create a longer search back through the form. That does not automatically justify live validation everywhere. It makes selective early feedback worth testing.

There is also a difference between guidance and an error. A password checklist can explain requirements while someone types without treating each incomplete requirement as a failure. A date hint can explain the booking window before a value exists. Useful help need not wait for submission, and early help need not look like a red warning.

Write down which fields use which trigger. Otherwise, “we validate inline” can conceal three different behaviors implemented by three different people.

Write the correction the system can actually justify

“Enter a valid email address” is often the end of the conversation when it should be the beginning. What does valid mean here? Missing, malformed, unavailable, and unverified are different states. Treating them as synonyms creates confident-sounding messages that do not explain the next action.

For a fictional workshop form, an empty contact field could say, “Enter an email address for your booking confirmation.” If the entered text has no @ sign, “Enter an email address with an @ sign” describes an observable problem. Neither sentence establishes that the mailbox exists or belongs to the person. That would require a separate verification step.

The temptation is to write an extremely specific message for every possible typo. I would resist that unless the validation logic can reliably distinguish them. A sentence saying the domain is misspelled is unhelpful if the person uses an unfamiliar but legitimate domain. When the system is uncertain, an optional suggestion can be better than a hard refusal. The team needs to agree on the difference before the copy is approved.

Here is a small message inventory for that workshop example. Each row begins with a condition, because the same field can need several different messages.

The final row deliberately asks more of the product than a sentence. A status-check instruction is only appropriate if the service offers a usable way to perform it. If it does not, the design needs another recovery path agreed with engineering and support. Copy should expose that missing decision, rather than disguise it with “Please try again.”

Make a long form navigable after failure

Imagine pressing Continue near the bottom of a booking page. Two fields near the top now have errors, but the viewport still shows the button. A red border somewhere offscreen is not enough. The person needs to discover that the action failed and get back to the answers that need attention.

In our workshop example, a summary can name the seat count and date issues, with each entry linking to its field. The inline text then stays beside the answer during correction. This repetition has a purpose: the summary helps someone travel; the local message helps them edit. Giving the two locations different wording adds an unnecessary translation task.

The summary should also be selective. A contact email that passed the relevant checks does not belong in the error list. Nor should the whole form be cleared to create a tidy reset state. Seeing the previous answer helps someone understand what happened and change only what is necessary. For sensitive information, retention needs its own product and security decision; do not promise that every field will always be stored.

This is where a static design review needs to become an interaction review. Follow a summary link using the keyboard. Check where focus lands, whether the field’s label remains visible below a sticky header, and whether its explanation is available when the field is reached. Then make the correction and submit again. A screenshot can show a red box; it cannot establish that this route through the page works.

On mobile, review the same sequence with the keyboard open. A message may fit beautifully in a desktop frame and sit beneath the keyboard on a phone. Long errors should wrap, not shrink into unreadable type. I would rather give a correction another line than make the person zoom into the instruction needed to finish.

The message must change when the facts change

A common review mistake is approving only two frames: normal and error. The awkward part often lies between them. Someone edits an answer, the original problem disappears, and the red message remains. From their perspective, the correction may have failed.

For the workshop form, suppose four seats were requested and only two remained. Changing the quantity to two should trigger a fresh check of the applicable rule. Changing the date is different: it changes which inventory the rule depends on. A warning about the previous session cannot simply remain attached to the new one. The relationship matters more than the red border’s appearance.

I would ask for three additional states in a handoff: checking, accepted for this step, and unable to check. “Checking availability…” is not the same as “Two seats available,” and neither is a booking confirmation. These distinctions keep the interface honest when a request takes longer than expected or a session sells out between checks.

There is a less visible edge case too. A person changes the date twice, and the first availability request finishes after the second. If the older response overwrites the newer one, the interface can present a perfectly legible answer to the wrong question. The design notes should require results to correspond to the current selection; engineering can choose how to enforce that.

When reviewing motion or loading treatments, keep this state distinction in view. The goal is not to make the transition look busy. It is to prevent a person from interpreting an old result as a new one. If the system cannot check right now, a neutral explanation is more accurate than marking their answer invalid.

A service failure is not a badly answered question

The most expensive wording mistake in a booking flow may be telling someone to correct an answer that was never wrong. A failed request can mean the input was rejected, the server was unavailable, or the outcome is unknown. Those possibilities require different next steps.

Take a timeout after the person presses Book. The request may not have reached the service. It may also have completed while the response was lost. Without knowing which happened, “Your booking failed” is too certain. An immediate second submission might be harmless, or it might create a duplicate. The product needs an explicit decision about that uncertainty.

For our example, I would review the recovery route with an engineer before polishing the message. Can the service retrieve the outcome using a request reference? Does a repeat request safely return the original result? Can support find the attempt? Which answers remain on the page? These questions determine whether the right next action is checking status, retrying safely, or contacting support with a reference.

This is not a reason to put technical internals into the error text. The reader does not need a lecture about network failures. They need an honest statement of what is known and a next step that works. A request reference can be useful if support can use it; an unexplained error code is just another problem for the person to interpret.

Form validation best practices include the recovery path

In OpenDesign, a supported HTML preview can help a team compare the normal field, the error, and the corrected state. Use realistic values and a long message, inspect a narrow viewport, and comment on the specific element that needs changing. Then test the same sequence against the working backend, keyboard flow and screen-reader announcements.

A small review session can be more revealing than another round of adjectives. Give someone a concrete task, such as booking four workshop seats, and let them encounter the capacity conflict. Ask what they think happened and what they would do next. Avoid explaining the intended meaning first; that would remove the very ambiguity you are trying to discover.

Watch what they do after the correction as carefully as what they say about the message. If they repeatedly reread the warning, perhaps it has not cleared. If they change a valid email after a service timeout, the interface may be assigning blame to the wrong place. If they restart the whole form, the recovery route may be harder to find than the original task.

For a live service, repeated submissions and correction loops can help identify where to investigate. They do not automatically explain the cause. A high error count might reflect confusing instructions, an overly restrictive rule, unavailable inventory, or an implementation defect. Combine the event sequence with observed behavior, and avoid collecting raw personal answers simply to diagnose the form.

Before approving the example, I would walk through this short sequence:

1. Enter an incomplete answer and observe when feedback appears.
2. Submit with two errors and reach both fields from the summary.
3. Correct one answer and confirm that unrelated values remain.
4. Change a dependent answer, such as the workshop date, and inspect the new result.
5. Encounter an unavailable service and follow its recovery route.

The final check is the successful result. Does the confirmation show the corrected date and quantity? Can the person tell whether a booking exists? A form has not recovered merely because the red text has disappeared.

Good form validation error messages leave less work for the person to interpret. The industry examples are useful because they reveal where that interpretation breaks down: before an answer is finished, after a correction is made, or when the interface claims to know more than it does. Borrow the reasoning, test it in your own task, and let the sentence follow the behavior you can actually deliver.