A form error message has one job: help someone get past a problem and continue. “Something went wrong” does not do that. Neither does a red border with no explanation.
Useful messages name the issue in plain language, point to the field that needs attention, and give a workable next step. They also appear at the right time and remain available to people using a keyboard or screen reader.
This guide explains how to write form error messages, with examples for common business forms. The aim is not to prevent every mistake. It is to make mistakes easy to understand and correct.
What a helpful form error message needs to do
When someone sees an error, they should be able to answer three questions:
- What went wrong? Identify the specific problem.
- Where did it happen? Name or clearly associate the relevant field.
- What should I do next? Give a practical correction or explain what information is needed.
For example, “Enter a valid answer” leaves all three questions open. “Enter your email address in a format like [email protected]” identifies the field, explains the issue, and shows a format to use.
Not every message needs to include an example. If a phone number field accepts several formats, demanding one exact format may create unnecessary work. Give instructions only when they help someone complete the task.
Write the message around the actual problem
Start with the validation rule, not a stock phrase. Ask what condition the form checks and what a person can do about it. Then describe that in everyday language.
Say what is missing or invalid
Replace vague messages with a specific description:
- Vague: “Invalid input.”
Clearer: “Enter a 5-digit ZIP code.” - Vague: “Please correct this field.”
Clearer: “Choose a delivery date after today.” - Vague: “There was a problem with your file.”
Clearer: “Upload a PDF or Word document. The file must be smaller than 10 MB.”
Be precise about limits. If a message says “too long,” state the maximum length. If a date must be within a certain period, give the boundary or explain how to choose an eligible date.
Use neutral, respectful language
Describe the input, not the person. “This email address is missing a domain, such as example.com” is more useful than “You entered your email incorrectly.” Avoid scolding language such as “Oops, you forgot…” or “You did this wrong.” A person may have misunderstood the question, encountered a technical problem, or used a format your form did not anticipate.
Keep the tone calm. A friendly voice is fine, but jokes and exclamation marks can distract from an error that needs attention—especially in a payment, health, or application form.
Give an example when the format is not obvious
Examples are useful for unfamiliar or restrictive formats: a date written as day/month/year, a reference number with a fixed number of characters, or a password with specific requirements. Put the expected format near the field before submission when possible, then repeat the relevant instruction in the error message.
Do not use examples that look like real personal data or could be mistaken for the person’s own answer. A placeholder such as “e.g., AB-12345” is clearer than a populated field that someone must delete.
Match the message to the kind of error
Different errors call for different instructions. A general “required field” message is not enough when someone needs to know which information is acceptable.
Required fields
For a missing required answer, name what is needed: “Enter your company name” or “Select a preferred appointment time.” Mark required fields before submission as well, using a visible label or an explanation near the form. Do not make people guess whether an empty field is optional.
If a field is not essential, consider making it optional rather than blocking submission. Wefom’s guide to deciding when a form field should be optional can help teams make that call.
Format and range errors
Explain the requirement that was not met, using the simplest useful wording:
- “Enter a date in day/month/year format, for example 24/10/2026.”
- “Enter a number between 1 and 20.”
- “Use the 8-character booking code from your confirmation email.”
Check that the example matches the form’s locale and accepted formats. A date example that means different things in different countries can create another error.
Conditional and dependent questions
If a follow-up question appears only after someone selects an option, make the error refer to that choice or field by its visible label. For example: “You selected ‘Other.’ Describe your request so we can route it to the right team.” This is more useful than “Additional information required.”
When a person changes an earlier answer, check whether dependent answers should be cleared, retained, or revalidated. If the form removes an answer, explain why rather than silently discarding information.
System and submission errors
Sometimes the problem is not a particular answer. A network failure, expired session, or temporary service issue may stop submission. Say what happened as far as you know and give a safe next step: “We couldn’t send your request. Your answers are still on this page. Check your connection and try again.”
Do not claim that answers have been saved unless they have. If someone needs to contact support, provide a useful route and any non-sensitive reference number they can share. Never expose internal error codes or technical details that help attackers or confuse the person filling out the form.
Put errors where people can find and understand them
Good wording cannot compensate for an error that is hard to locate. For a field-level problem, place the message close to the relevant field, usually beneath its label or input. Keep the field label visible; do not rely on a placeholder, color, or position alone to identify it.
For a form with several errors, add a summary near the top that says how many issues need attention and lists links or clear references to the affected fields. For example: “There are 2 problems with your request: enter a contact email and choose a delivery date.” The summary helps people see the overall task; the messages by the fields explain how to fix each issue.
After submission, move keyboard focus to the summary or otherwise make the errors easy to discover. If the form is long, a person should not have to scan from the beginning to find a message near the bottom. When a field is corrected, remove or update its error so the interface does not keep presenting a resolved problem.
Do not communicate errors through color alone. A red outline can reinforce an error, but pair it with text and an appropriate visual marker. The W3C’s WCAG guidance on error identification says that detected errors must be identified and described in text.
Make errors work with assistive technology
People who use screen readers need to know both that a field has an error and what the error says. The message should be programmatically associated with its field, and the field’s error state should be conveyed to assistive technology. These details usually require correct HTML and form behavior, not just visible styling.
When submission reveals several errors, make the summary announcement and navigation predictable. Avoid announcing every error repeatedly as a person moves through the form. For dynamic validation—for example, an error that appears after leaving a field—ensure it is announced without unexpectedly moving focus.
WCAG also addresses error suggestions: when a correction is known and it is appropriate to provide it, explain how to fix the error. See the W3C’s guidance on error suggestion. There can be exceptions, such as situations where revealing a correction would compromise security.
Use automated accessibility checks as one part of testing, not as proof that errors are understandable. Try the form with a keyboard and, where possible, a screen reader. Confirm that the field label, error message, and required or invalid state are announced in a useful order.
Choose the right moment to show an error
Showing an error too early can interrupt someone who is still entering an answer. Showing it too late can leave them with a long list of surprises after submission. The right timing depends on the field and the form.
For many forms, validate required fields and cross-field rules when a person submits. For a field with a clear format, validation after the person leaves the field can help—provided it does not flash an error while they are still typing. Avoid changing or rejecting an answer before someone has had a reasonable chance to finish entering it.
Use the same rules and wording in the browser and on the server. Browser checks can catch simple mistakes quickly, but server-side validation is still needed because browser checks can be bypassed or fail. If the server rejects an answer, return the person to the form with their other answers preserved wherever possible.
Long forms may benefit from a different structure, but splitting a form into steps does not remove the need for clear errors. Consider the task and how people move through it; this guide to multi-step versus single-page forms covers the trade-offs.
A practical review checklist
Before publishing or updating a form, test its error messages with realistic mistakes. For a small-business contact form, you might leave the company field blank, enter a malformed email, attach an oversized file, and disconnect before submission. Check each result against these questions:
- Does the message identify the exact field or issue?
- Does it say what to do, not just that something is wrong?
- Are formats, limits, and examples accurate?
- Can someone find the error visually and by keyboard?
- Is the message associated with its field for assistive technology?
- Does the form preserve answers after an error?
- Is a resolved error removed or updated?
- Does a system error avoid promising that data was saved when it was not?
Ask someone unfamiliar with the form to correct a set of intentional mistakes. Watch where they hesitate, what they misunderstand, and whether the message leads them to a successful correction. A message that seems obvious to the person who built the form may depend on context that a customer, applicant, or colleague does not have.
Frequently asked questions
How long should a form error message be?
As short as possible while still explaining the problem and next step. “Enter a date after today” is concise and actionable. Add a format example or boundary when the person needs it to answer correctly.
Should error messages appear beside fields or at the top of the form?
Use both when a submission has multiple errors: a summary near the top helps people understand what needs attention, and a message beside each field explains how to fix it. For a single, simple error, a field-level message may be enough, but make sure it is easy to discover.
Should a form show errors while someone is typing?
Usually not for incomplete answers. Validate after submission or when someone leaves a field, depending on the form. If you validate on blur, avoid showing an error before the person has had a fair chance to finish the answer.
What should I say when the form cannot be submitted?
State that submission failed, say whether the answers are still available only if you know that is true, and give a next step such as trying again or contacting support. Do not expose raw technical errors.
Are red borders enough to show an error?
No. Color can reinforce the message, but the problem must also be identified in text. Keep the error close to the relevant field and make its relationship to that field clear to assistive technology.