Treat an error as a request for help
A form often sits at an important point in a visitor’s journey: making an enquiry, requesting a service, or signing up for updates. When something goes wrong, the error message should help the person complete that task. “Invalid input” describes a problem from the system’s point of view. “Enter an email address in the format name@example.com” gives the person a next step.
Start by identifying the mistake the form can actually detect. A blank required field, an incorrectly formatted email address, and a password that does not meet stated requirements need different messages. Use ordinary words and name the field where it helps: “Enter your email address” is clearer than “This field is required.” Do not claim to know why someone made a mistake. If the form cannot determine whether an address exists, it should not say that the address is wrong.
Keep the tone calm and direct. Avoid jokes, blame, and unnecessary apologies. Someone correcting a form may already be frustrated or using an unfamiliar device. A short, useful instruction respects their time.
Write the instruction before the error
The best error message cannot compensate for confusing instructions. Before someone submits a form, show what is required and explain any unusual format beside the relevant field. If a contact form needs a phone number only for urgent requests, say why it is requested and whether it is optional. If a date must be entered in a particular format, show an example near the field rather than waiting for a failed submission.
When an error is needed, make it specific enough to act on. For an empty message box, “Enter a brief description of what you need” is more helpful than “Missing information.” For a date that must be in the future, “Choose a date after today” explains the rule. If the person entered a date that cannot exist, “Enter a valid date, such as 15 June 2026” illustrates the expected form, although the example should match the format your form accepts.
Rules should also match the task. Do not require a street address for a simple newsletter signup or reject a person’s name because it contains a space or punctuation mark. Fewer unnecessary restrictions mean fewer errors for people to resolve.
Put each message where people can use it
Place an error beside the field that needs attention, and keep the field label visible. If several fields need fixing, a short summary at the top can tell people what happened and link to each affected field. For example, the summary might say “There are two things to fix before you send your enquiry,” followed by the field names. The nearby messages then give the specific instructions.
Do not rely on red text alone to communicate an error. Pair colour with words so the message remains understandable when colours are hard to distinguish. Make sure the error is connected to its field in the form’s markup and announced appropriately by assistive technology. When submission fails, help keyboard and screen-reader users find the errors without making them search the entire page.
Preserve the information the person already entered. If the email field needs correction, their carefully written enquiry should still be there. After they make a change, clear an error only when the issue has been resolved, and avoid showing errors while someone is still typing a reasonable response.
Handle failures the visitor cannot fix
Not every failed submission is a field error. A connection may drop, an attachment may exceed an allowed size, or the form may be temporarily unavailable. Tell people what you know and offer an appropriate next step. “Your file is larger than the 10 MB limit. Choose a smaller file and try again” is actionable. If the form did not send for an unknown reason, say so rather than pointing to a field that may be correct.
For an enquiry form, a general failure message could say: “We couldn’t send your enquiry. Your message is still here. Please try again.” If there is another contact method already provided by the organization, you can point to it. Avoid promising that an enquiry was received unless the submission was confirmed. A clear success message matters for the same reason: people need to know when they are finished.
Use a small-team review workflow
You do not need a large project to improve an existing form. List each field, the instructions shown before submission, the errors the form can produce, and what a person should do next. Rewrite vague messages using a simple pattern: name the problem, then state the action. Check that the wording matches the form’s actual rules; a helpful-sounding message is still frustrating if following it does not work.
Next, test the form by leaving required fields blank, entering plausible mistakes, using only a keyboard, and trying it on a narrow screen. Check whether the messages are easy to find, whether previously entered answers remain in place, and whether a corrected submission succeeds. If possible, ask someone unfamiliar with the form to complete a realistic task and describe any point where they are unsure what to do.
Keep a short record of repeated problems reported by visitors or staff who handle enquiries. If people regularly misunderstand the same field, revise the label or instruction before adding more error text. The goal is not a clever message for every failure; it is a form that helps people finish with as little correction as possible.
