Last updated: May 9, 2026
A form error message is not there to blame the user.
It is there to help the user finish.
"Required." "Invalid." "Something went wrong."
These messages may be technically true, but they often do not explain what happened or how to fix it. On mobile, vague errors are even more expensive because the field may be out of view and the respondent may keep pressing submit without knowing what to change.
This guide gives practical form error message examples, placement rules, accessibility notes, and FORMLOVA setup prompts.
For the broader form completion workflow, read the Form Conversion Optimization Guide. This article focuses specifically on validation and error copy.
Quick Answer: Say the Field, the Problem, and the Fix
A good form error message usually contains three things:
which field has the problem
what the problem is
how to fix it
Weak:
There is an error.
Better:
Enter your email address.
More helpful:
Enter your email address. Example: name@example.com
WCAG 2.2 guidance explains that when input errors are detected, users should receive text that identifies the error and the item in error. When a correction is known, users should also receive a suggestion.
Color alone is not enough.
Tell people what to fix in text.
Error Message Examples by Field Type
Use these as starting points.
Required Fields
For required fields, include the field name.
| Weak | Better |
|---|---|
| Required | Enter your name. |
| Please fill this out | Enter your company name. If you are an individual, enter "Individual." |
| Missing | Enter your message. |
The field name alone removes a lot of uncertainty.
Email Address
Separate missing input, invalid format, and mismatch errors.
Enter your email address.
Enter an email address in this format: name@example.com
The confirmation email address does not match.
"Invalid format" is too abstract. An example gives the respondent a fast correction path.
Keep the example short. Long explanations inside error text become hard to scan.
Phone Number
Decide how you handle hyphens, spaces, and country codes.
Enter your phone number.
Use numbers only.
Enter a phone number with 10 or 11 digits.
If hyphens are allowed, say so:
Enter your phone number. Hyphens are optional.
If the form can normalize hyphens or spaces automatically, let the form do the work instead of forcing a strict format on the respondent.
Dates
For dates, separate format and range errors.
Select your preferred date.
Use this date format: 2026/05/09.
Past dates cannot be selected.
Choose a date within the next 30 days.
Even with a date picker, explain why a date is not available when the user reaches a boundary.
Numbers
For quantities, headcounts, and budgets, show the allowed range.
Enter the number of attendees.
Enter at least 1 attendee.
Enter 100 attendees or fewer.
"Enter a number" does not explain the range.
File Uploads
For file uploads, separate file type, size, and count.
Choose a file to upload.
Upload a PDF, PNG, or JPG file.
Upload a file under 10 MB.
You can upload up to 3 files.
The same rules should also appear before the error, near the upload field. Do not make people discover file requirements only after failing.
Privacy or Consent Checkbox
Consent checkbox errors should say what the consent refers to.
Agree to the privacy policy before submitting.
Review the privacy policy and select the consent checkbox.
"Please agree" is vague if the page contains more than one statement.
For the consent wording itself, read the Contact Form Privacy Consent Wording Guide.
Where to Display Error Messages
Display field-specific errors near the field.
A single message above the submit button that says "there are errors" is not enough for a long form. The user still has to search.
A practical pattern is:
top of form: summarize that corrections are needed
near each field: explain the specific fix
after submit: move focus to the first error
Top summary:
Please fix 3 fields before submitting.
Review the messages below.
Field-level message:
Enter an email address in this format: name@example.com
The summary announces the situation. The inline message helps the user fix it.
Use both for longer forms.
Do Not Rely on Color Alone
Red borders are common.
They are not enough.
Some people cannot distinguish the color cue. Screen readers do not announce "this field is red" as the instruction the user needs. WCAG's error identification guidance focuses on presenting the error in text or a text alternative.
Use a combination:
show error text
place it close to the field
use border or icon as a supporting cue
include examples only where helpful
Icons and borders can help scanning.
They should support the text, not replace it.
Prevent Errors Before They Happen
Helpful error messages matter.
But the better form is the one that prevents avoidable errors.
Examples:
Show an example near the email field.
Use a date picker for dates.
Use a select field for small fixed ranges.
Accept phone numbers with or without hyphens.
Keep required fields minimal.
Add short instructions before complex fields.
WCAG's Labels or Instructions guidance explains that form controls should have labels or instructions so users know what information is expected.
Do not only help after failure.
Help before the error happens.
Design Error Copy in FORMLOVA
In FORMLOVA, form creation can include the field structure, helper text, and the intended validation behavior in the same conversation.
You can ask:
Create a contact form.
For the email field, show an example format.
Accept phone numbers with or without hyphens.
Use error messages that explain what to fix.
For a hiring form:
Create a job application form.
The resume upload should accept PDF only and files under 10 MB.
If the file is wrong, show separate messages for file type and file size.
If you are still deciding which fields to include, read the Form Field Examples Guide. Error copy is easier when field names, input formats, and required/optional rules are already clear.
Common Mistakes
Saying Only "Invalid"
Invalid according to what?
Show the expected format, example, or range.
Showing Every Error Only After Submit
Long forms become tiring when all errors arrive at the end.
Show errors during entry when the rule is clear, and reserve server-side errors for rules that genuinely require submission.
Clearing the User's Input
If the form fails and all entered values disappear, many people leave.
Keep the existing input whenever possible.
Making Formats Too Strict
Phone number hyphens, postal code spacing, and company-name punctuation are often better normalized by the form than forced onto the respondent.
Do not make people adapt to your parser when your parser can adapt to them.
Summary
Good form error messages are small, but they carry a lot of responsibility.
They should identify the field, explain the problem, and suggest the fix.
Use text, not color alone. Place the message near the field. Keep entered values after failure. Prevent predictable errors with labels, examples, and input controls.
An error message is not the form's failure state. It is the user's path back to completion.
Disclosure and Verification
- Verified on: May 9, 2026
- Main official sources checked:
- FORMLOVA implementation checked:
lib/form/validation.ts,lib/form/types.ts, and the public form submission flow were reviewed for general validation context. - Note: Accessibility conformance depends on the final HTML, focus behavior, labels, descriptions, and assistive technology testing. This article is a practical wording and design guide.
