Error messages that help instead of frustrate users

When someone encounters an error in your form, they are one moment away from leaving. Studies show that over 75% of users abandon forms when errors appear and they cannot immediately fix them. That is not a small problem. That is three out of four potential customers, leads, or signups walking away. The difference between keeping them and losing them often comes down to a single thing: the error message. A confusing error message sends them away. A clear, helpful error message brings them back and gets them to complete the form.

An error message is your form's chance to guide someone toward completion when they make a mistake. A bad error message (one that is vague, blame-focused, or unhelpful) makes the user feel confused or at fault. A good error message tells them exactly what went wrong, why it matters, and how to fix it in plain language. This article covers how to write error messages that work, where to place them so they cannot be missed, what tone actually builds trust, and why specificity is the difference between abandonment and completion.

What makes an error message effective

An effective error message does three things. First, it clearly states what went wrong. Not "Invalid input." Instead, "Email addresses need an @ symbol." Second, it explains why the input was rejected if that helps. "Passwords must be at least 8 characters because shorter ones are easier to hack." Third, it tells the user exactly what to do next. "Go back to the password field and add at least 4 more characters." The user now knows the problem, understands why it matters, and knows how to fix it.

The tone of an error message matters more than most people realize. An error message that sounds angry or condescending makes the user feel blamed. "You forgot the @ symbol" feels like their fault. "Email addresses need an @ symbol" is the same information but without blame. A helpful tone acknowledges the mistake without making the person feel bad about it.

The timing and placement of an error message determine whether the user even sees it. An error message that appears three screens below the field that caused it is easy to miss. An error message that appears next to the problematic field, the moment they try to move on, forces them to notice it and fix it immediately.

Inline validation vs. submission validation

Inline validation shows an error message the moment someone fills in a field incorrectly, before they submit the form. A password field shows an error as soon as they type a password that is too short. An email field shows an error as soon as they leave the field without an @ symbol. Real-time feedback is powerful because people fix mistakes immediately instead of discovering them after completing the entire form.

Inline validation does one thing especially well. It builds confidence. When someone types an email address and sees a green checkmark appear, they know they got it right. They move forward without doubt. Without that confirmation, they wonder if their input was correct and second-guess themselves.

Submission validation is what happens when someone clicks submit and the form checks all fields at once. If any field has an error, a validation summary appears listing all problems at the top of the form, and each field with an error is highlighted. Submission validation catches errors that inline validation missed and gives users a complete picture of what needs to be fixed.

The best approach is both. Use inline validation for fields that can be checked instantly (email format, password length, zip code format). Use submission validation as a final safety net. When someone clicks submit, if any field still has an error, show them immediately what needs to be fixed before they can submit.

Writing error messages that are specific and actionable

A specific error message tells the user exactly what the problem is. A generic error message leaves them guessing. Compare these two:

Generic: "Invalid phone number."

Specific: "Phone numbers need 10 digits. You've entered 9. Add one more digit."

The generic message tells the user what is wrong but not why or how to fix it. The specific message tells them the problem, why it happened, and exactly what to do. The specific message takes slightly longer to read but saves the user minutes of frustration.

An actionable error message includes instructions. "Passwords must contain at least one number" tells them what is missing. "Passwords must contain at least one number. Go back to the password field and add a number." tells them what to do. For forms, the instruction is usually obvious (go back to the field), but spelling it out helps people who are unfamiliar with forms or who are using assistive technology.

Use plain language. Not "Zip code format incorrect." Instead, "Zip codes are 5 numbers. You've entered letters." Not "Invalid email format." Instead, "Email addresses need an @ symbol and a domain (example: name@company.com)."

Placement that makes errors impossible to miss

An error message placed far from the field that caused it is easy to miss. When someone fills a form with many fields, they focus on each field one at a time. An error message that appears at the bottom of the form while they are still focused on the top goes unseen.

The best placement for an error message is directly below or beside the field that has the error. When they move to the next field or try to submit, an error message appears immediately under the field they just filled. They cannot avoid seeing it because it appears where they expect the next action to be.

For a validation summary (listing all errors at once after submission), place it at the top of the form. This gives the user a complete view of all problems. Then, as they scroll down, the individual field errors appear again next to each field they need to fix. This dual approach serves two purposes: it shows them the full scope of what needs fixing, and it reminds them as they work through each field.

Never use toast error messages in forms. A toast is a notification that appears briefly in the corner of the screen and then disappears. For forms, this is the worst placement possible. The error appears far from the field that caused it. It disappears before the user has time to read it. It creates a disconnect between the problem and the place to fix it. If an error message must disappear, it should only be after the user has successfully fixed the field.

Visual design of error messages

Color alone is not enough to communicate an error. Someone with colorblindness may not see the red color that signals an error. A very small error icon might be missed by someone with low vision. Rely on multiple signals: color plus text plus icon.

A red border around the field. A red or orange icon next to the error message. Text that clearly states the problem. All three together create an error state that nearly everyone can recognize.

Font size matters. Error message text should be the same size as the field label. If the error message is smaller, people might miss it or think it is less important than it is. The error message deserves the same visual weight as the label.

The label of the problematic field can also change. The label text can turn red or bold. This creates another visual signal that helps the user scan the form quickly and find the field that needs attention.

Tone and politeness in error messages

Error messages should sound like you are helping someone, not blaming them. Avoid words that sound harsh or accusing.

Harsh: "You entered an invalid email address."

Helpful: "Email addresses need an @ symbol. Check your entry and try again."

Harsh: "Password is too weak."

Helpful: "Passwords need at least 8 characters. Longer passwords are safer."

Harsh: "You forgot to fill in this field."

Helpful: "This field is required. Let us know what you think."

A helpful tone acknowledges the mistake without making the person feel bad. It explains why the rule exists (when helpful). It moves forward without dwelling on the error.

Common error message mistakes

The most common mistake is being too vague. "Invalid input" tells the user nothing. "Something went wrong" is equally unhelpful. Be specific about what the problem is.

A second mistake is using technical language. "Regex mismatch" or "Validation failed" might mean something to engineers, but regular people have no idea what these terms mean. Translate technical errors into plain language.

A third mistake is showing too many errors at once. If a form has 20 fields and all 20 show errors, the user feels overwhelmed. Prioritize which errors are critical (like a required field that is empty) and show those first. Secondary errors (like a field that has a formatting issue but is optional) can be shown second.

A fourth mistake is error messages that repeat the label without adding new information. The label says "Email address." The error message says "Email address is invalid." The user already knows which field has the problem (they can see the red border), but they still do not know why it is invalid. The error message should add information, not repeat the label.

A fifth mistake is not offering a path to fix the problem. "Password does not meet requirements" tells the user something is wrong but not what the requirements are. "Password does not meet requirements. Passwords need at least 8 characters and one number" tells them what to fix.

How WEMASY helps you create clear error messages

WEMASY's form builder includes predefined error messages for common field types. Email fields show "Email addresses need an @ symbol" when the format is wrong. Phone fields show "Phone numbers need 10 digits" when the length is incorrect. Password fields show password strength requirements as the user types. These messages are clear, specific, and helpful by default.

You can customize error messages to match your brand's tone. Change the message from "Email addresses need an @ symbol" to "Oops, that does not look like an email. Try again?" The tone changes but the specificity remains. You control how the message sounds without sacrificing clarity.

For custom validation (fields with specific rules unique to your form), you can write your own error messages directly in the form builder. The system helps you place the message next to the field, show it at the right time (inline or on submission), and style it to match your form design.

Real-time validation is built in, so error messages can appear as users type, not just after they submit. This catches mistakes early and prevents the frustration of completing an entire form only to discover problems at the end.

See what form features are included in your WEMASY plan.

Frequently asked questions