How to Write Form Error Messages That Don't Lose Users

This guide covers form error messages from start to finish: where they go, when they appear, how they sound, what accessibility standards require, and what to check before launch. For the wider picture of form layout, field count, and buttons, see our article on what increases and hurts conversions in web form design. Here we focus on one moment only: the text you show when something goes wrong.

At Talha Aslan and team, we have worked on business websites, quote forms, and checkout steps since 2012. We keep seeing the same pattern. Visitors usually want to finish the form. What pushes them away is rarely the error itself. Instead, it is the way the error is explained. That is why we treat message copy as part of the design, not an afterthought.

Which three questions should every error message answer?

Every error message should answer three questions that form in the user's mind. First, where is the problem? Second, what exactly is wrong? Third, what do I need to do to fix it? A message that skips any one of these forces the user to guess. Guessing also costs time and patience.

• Location: The message appears next to the field it belongs to and names that field.
• Cause: Instead of "Invalid input," it names the issue, for example "The email address is missing an @ sign."
• Fix: It shows the expected format, for example "Use the format name@example.com."

For example, imagine a phone field that only says "Invalid." Should the user add a country code? Remove spaces? Or is a digit missing? By contrast, "Enter a 10 digit phone number without the leading zero" answers all three questions at once. As a result, the user usually gets it right on the second try.

This structure also matches the broader principles of interface copy. We explain how we approach short interface text in our guide to UX writing and website microcopy. Error messages are simply the part of that discipline that gets tested the hardest.

What does WCAG require for form error messages?

The Web Content Accessibility Guidelines (WCAG) are the international accessibility standard published by the W3C. Two success criteria deal directly with error messages. Together, they give you the core framework for both compliance and good user experience.

WCAG 3.3.1 Error Identification (Level A) says that when an input error is automatically detected, the item in error must be identified and the error described to the user in text. According to the W3C, simply redisplaying a form after a failed submission, with no message, does not meet this criterion. You can add color or icons. However, the text itself is mandatory.

WCAG 3.3.3 Error Suggestion (Level AA) goes one step further. If the system detects an error and knows how to fix it, you should offer the user a suggestion. The only exception is when a suggestion would jeopardize security or the purpose of the content. For instance, you would never reveal the correct password on a login form.

Put simply, 3.3.1 answers "what is wrong," and 3.3.3 answers "how do I fix it." For the full picture of accessibility standards, read our article on web accessibility and WCAG standards.

Where should an error message appear on the screen?

The safest position is directly below or above the field with the problem. The Nielsen Norman Group guidelines for reporting errors in forms also recommend keeping the message next to the field. That way, users do not have to remember the message after reading it. After all, their eyes are already where the fix needs to happen, so the message lands at the right moment.

On the other hand, showing only a single alert at the top of the form makes users scroll back and forth, especially on long forms. Likewise, hiding the message inside a tooltip behind a small warning icon causes trouble. These icons are easy to miss, so users need an extra action just to read the message.

• Place the message below the field, aligned with the label.
• Reserve space in advance so the layout does not jump when the message appears.
• If there are several errors, show each one next to its own field.
• Create a clear visual link between message and field: same container, same icon, short distance.

Also think about mobile when you decide on placement. On a narrow screen, a message to the right of the field tends to overflow or get cut off. Therefore, placing it below is almost always the more robust choice.

When should inline validation trigger?

Inline validation means checking each field and giving feedback before the user submits the form. With the right timing, it helps a lot. With the wrong timing, however, it turns into an interface that scolds people before they have finished typing.

The practical rule is simple: validate when the user leaves the field. The web.dev guide to form validation shows validation on the blur event, which fires when the user moves out of a field. NN/g also advises against showing errors before input is complete. In other words, telling someone "invalid email" after they type three letters is a mistake.

That said, there is one exception. Once a user starts correcting a field that already shows an error, removing the message as soon as the value becomes valid is a good experience. That way, the person sees the fix right away. In short, show errors late and confirm fixes early.

The same logic applies to CSS. According to web.dev, the :invalid selector matches fields before any interaction, which can confuse users. Instead, it suggests :user-invalid, which only applies after the user has interacted with the field. Painting an empty form red on page load tells visitors they failed before they even started.

Why is color alone not enough to show an error?

A red border is a familiar error signal. However, it is not enough on its own. WCAG 1.4.1 Use of Color requires that color is not the only visual means of conveying information. The W3C lists marking required or error fields with color differences only as a failure of this criterion.

A user with color blindness may not tell a red border from a gray line. Likewise, someone looking at a phone in bright sunlight faces the same problem. So add at least one cue that does not depend on color:

• Visible text that explains the error (mandatory).
• A warning or exclamation icon.
• Thicker or differently styled field borders.
• A prefix such as "Error:" at the start of the message.

When you do use color, check the contrast too. For example, light red text on a pale pink background is hard to read. You can measure the ratio between text and background in seconds with our color contrast checker. As a result, the message stays readable for people with different color perception and for everyone else.

How do screen reader users hear an error?

An error message that looks perfect on screen may not exist at all for someone using a screen reader. For this reason, you need to connect the message to the field in code. There are three main tools for this.

1. aria-invalid: Set it to "true" on a field that fails validation. MDN advises against setting it on empty required fields before the user tries to submit, because the person may still be filling in the form.
2. aria-describedby or aria-errormessage: These attributes link the error text to the field, so the message is announced when the field receives focus.
3. Live region: It lets the screen reader announce the error summary right after a failed submission.

Also remember to set aria-invalid back to "false" once the field is fixed. Otherwise, the screen reader keeps announcing a corrected field as invalid. In our experience, this small sync bug is one of the most common accessibility flaws on real sites.

Focus management also matters. When a submission fails, move focus either to the error summary or to the first invalid field. That way, keyboard users do not lose their place on the page.

What does an error summary at the top of the form do?

An error summary is a box at the top of the form that lists every error after a failed submission. On long forms, it gives users an overview: how many problems are there, and where? Still, it is not enough on its own. NN/g advises against relying only on a summary and recommends showing each error at its field too.

A good summary has a few traits. First, it states how many errors there are, for example "2 fields need your attention." Then it lists each item as a link to the related field. So when users click an item, they jump straight to that field. Letting users jump to the field in error also appears among the WCAG techniques.

On the other hand, on short forms, such as a newsletter box that only asks for a name and email, a summary adds clutter. Therefore, we recommend using it on forms with more than five or six fields and on multi step processes.

What are good and bad examples of form error messages?

The table below shows weak messages we often see in practice and better versions you can use instead. These are general patterns, so adapt them to your own field names and rules.

The numeric rules in the table (8 characters, 5 MB) are an example scenario only. Instead, write the real limits of your own system. If the rule in the message and the rule on the server do not match, users get errors even when they enter valid data.

How do you write error messages without blaming the user?

Tone is the invisible half of an error message. Phrases like "You entered it wrong" or "You made an invalid request" put the problem on the user. Yet in most cases, the real problem is a form that never explained the rule upfront. So focus the sentence on the situation, not the person.

• Write "Phone number must have 10 digits" instead of "You entered the wrong phone number."
• Avoid all caps and exclamation marks. "ERROR!" shouts and does not help.
• Remove technical terms. "Regex mismatch" means nothing to most users.
• Keep it short. One or two sentences cover most cases.
• Skip jokes. For a frustrated user, humor usually backfires.

On the other hand, excessive apologies are not needed either. A long message that opens with "We are so sorry, unfortunately..." delays the fix. A polite but direct tone works best. In other words, write what a helpful support agent would say in one sentence.

Finally, stay consistent. A form that sounds formal in one field and casual in the next loses trust. Then tie your error messages to a single style guide and use the same patterns across every form on the site.

Which message patterns fit each field type?

Each field type has its own typical causes of error. You can use the patterns below as a starting point and then adjust them to your own rules.

• Email: Missing @ sign, missing domain, or extra spaces. Show the expected format in the message.
• Phone: Number of digits and country code. If possible, let the system strip spaces and dashes on its own.
• Date: Past dates, closed days, or wrong format. If you use a date picker, disable unavailable days from the start.
• Password: List the rules below the field from the start and mark each rule as it is met.
• File: Size limit and accepted types. Show them next to the upload button in advance.
• ID or tax number: State the number of digits. However, do not explain the check algorithm in detail.

NN/g also suggests confirming successful entries on complex fields, such as a password strength meter or a username availability check. That said, adding a green check to every letter of a simple name field creates visual noise for no gain.

For example, on a booking form the date field tends to generate the most errors. We cover the overall structure of these forms in our article on booking, quote, and demo form design.

How should you explain server and system errors?

Some errors do not come from user input. Instead, they come from the system: a dropped connection, an expired session, a payment provider that does not respond, or a server error. In these cases, the user did nothing wrong. Therefore, the message should make that clear.

A good system error message answers three things. What happened? Did I lose what I typed? What can I do now? For instance: "The connection dropped. Your details are still on this page, so check your internet connection and send the form again." This sentence prevents panic and also shows the way forward.

Also offer an alternative contact channel. If the form keeps failing, show a phone number or an email address. That way, a technical problem does not cost you a potential customer, because the visitor still has a route to reach you.

You do not have to hide error codes completely. To help your support team trace the issue, you can add a small reference code below the message. Still, the main sentence should always be in plain language.

Why should you keep the user's input after an error?

The fastest way to lose a user is to clear the entire form because of a single error. Someone who filled in ten fields and sees everything wiped after submission will most likely close the tab. So keep the entered values in the fields, even if the page reloads.

That said, some fields must be cleared for security reasons. You should not refill passwords or card security codes. In that case, briefly tell the user why they need to enter it again: "For your security, please type your password again."

Also, do not delete the invalid value. When users can see what they typed, they fix it faster. For example, if "ali@gmial.com" stays in the field, the person spots the typo at once. Deleting the value and saying "invalid email" makes them start over.

On multi step forms, this rule matters even more. When users press the back button, the data from the previous step should still be there. On the forms we build, we always test whether data survives the move between steps.

How can you prevent errors before they happen?

The best error message is the one you never need to show. If you explain the rule before the error instead of after it, the number of errors drops naturally. web.dev also recommends communicating validation rules before users make mistakes and linking that explanation to the field with aria-describedby.

• Visible label: Do not use placeholder text as a label. It disappears as soon as users start typing.
• Format hint: Show examples such as "MM/DD/YYYY" or "(555) 123 4567" below the field.
• Correct input type: Choose the right type for email, phone, and numbers, so mobile devices open the right keyboard.
• Forgiving input: Let the system remove spaces, dashes, or brackets instead of warning users about them.
• Fewer fields: Do not ask for information you do not need.

The last point is in fact the most effective one. After all, every extra field is a new chance for an error. We look at the mental load that field count puts on users in our article on cognitive load and form fields.

You can also use the browser's built in validation as a base layer. However, the W3C notes that built in messages can be generic, can disappear, and may not scale with zoom. For this reason, we recommend writing the message copy yourself.

How should form error messages look on mobile?

On mobile, the screen is narrow and the keyboard covers half of it. As a result, a message that looks fine on desktop can end up hidden under the keyboard on a phone. The first rule for form error messages on mobile is to place the message directly below the field and make sure the page scrolls it into view when the field gets focus.

When a submission fails, move the user to the first invalid field. Otherwise, people tap the button, think nothing happened, and tap it again and again. A summary at the very top of the screen stays invisible to someone who is looking at the button at the bottom.

• Keep the message font size comfortable to read and avoid very small type.
• Leave enough space between the message and the next field.
• Do not show errors in a modal, because modals are hard to close on mobile.
• If you disable the submit button while errors exist, explain why in visible text.

Example scenario: a user fills in a service company's quote form on a phone and leaves the district field empty. The error shows up at the top of the page, while the user is still at the button at the bottom. The person assumes the form is broken and leaves. Moving the message below the field and shifting focus there prevents that loss.

What do repeated errors tell you?

If a user keeps getting an error on the same field, the problem is most likely the design, not the user. NN/g treats three or more repeated errors in one attempt as a sign of a design problem and recommends offering extra help.

In practice, extra help can take different forms. After the second error, you can show a more detailed explanation, suggest a sample value, or make support contact details visible. For example, on a tax number field, a note after the second error such as "Sole traders can also enter their personal ID number" may solve the user's real problem.

Still, the real fix should be permanent. Find out which field produces the most errors, then decide whether you need to change the rule, the label, or the hint. In short, repeated errors are a data source. Use them to improve the form instead of ignoring them.

How do you test and measure form error messages?

You can only call form error messages good after you test them. Before launch, fill in every field the wrong way on purpose: leave it empty, use the wrong format, exceed the limit. In each case, check that a message appears and that it answers all three questions.

1. Fill in the form using only the keyboard and trigger an error. Where does focus go?
2. Try the same flow with a screen reader. Do you hear the message?
3. Switch the screen to grayscale. Can you still spot the invalid field?
4. Zoom the page to 200 percent. Does the message get cut off?
5. Trigger the error on a phone with the keyboard open. Can you see the message?

After launch, look at behavior data. Specifically, session recordings and heatmaps show you where users get stuck. We explain the setup in our Microsoft Clarity guide. In addition, sending validation errors to your analytics tool as a separate event lets you see the most problematic field in numbers.

Do not forget the moment of success either. After all, positive feedback matters as much as error feedback. For that, see our guide to thank you page design after form submission.

What should your pre launch checklist include?

You can use the list below for every new form and every form update. Before handover, our team checks each item one by one.

1. Every validation rule has a visible error text.
2. The message sits next to the field and names it.
3. The message names the problem and suggests a fix (WCAG 3.3.1 and 3.3.3).
4. Text and an icon mark the error, not color alone (WCAG 1.4.1).
5. Contrast between message text and background is sufficient.
6. Validation runs when the user leaves the field, not while typing.
7. The error message and the aria-invalid state clear once the field is fixed.
8. After a failed submission, focus moves to the first error or the summary.
9. User input stays in place, except for sensitive fields.
10. Server errors show a plain language message and an alternative contact option.
11. The rules in the message match the rules on the server exactly.
12. On mobile, the keyboard does not hide the message.
13. Tone and form of address stay consistent across all forms.

A form that passes this list never leaves users stuck. After every error, it shows them the next step.

How do you handle error messages on a multilingual site?

If your site runs in more than one language, you need to write the error messages separately for each one. Machine translated messages often keep the meaning but break the tone. For example, a sentence that sounds polite in Turkish may feel too formal in German or too long in English.

Therefore, we recommend storing messages in one text file with separate keys for each language. That way, when you change a rule, you update the message in every language at once. Also, date, phone, and postal code formats differ by country, so adapt the format hint to both language and region.

Finally, watch out for default browser messages. If the visitor's browser language differs from your site language, the same page may show warnings in two languages. Writing your own messages removes that confusion too.

Which mistakes do we see most often?

When we review forms on business websites, some flaws come up again and again. Knowing them, in turn, helps you assess your own form quickly; so start with this list.

• A single generic message for every field: "Please check the form."
• Red borders all over the form the moment it loads.
• All fields cleared after submission.
• Reliance on default browser bubbles only, whose wording changes by browser and language.
• Values the front end accepts but the server rejects.
• Leftover system messages in another language than the site.

Most of these flaws need only a few lines of change. Sometimes, however, the problem sits in the form's foundation. For instance, the form plugin may not allow custom messages at all. In such cases, rebuilding the form often costs less than patching it again and again.

Who builds form error messages into your site?

Form error messages may look like a small detail, yet they sit where design, copy, accessibility, and development meet. Writing the text is the easy part, because anyone can draft a sentence. Making it appear at the right time, in the right place, linked to screen readers, and aligned with server rules takes a team.

At Talha Aslan and team, our web design service builds forms together with their error states, not just their visual layer. For every field, we write the rule, the hint, and the error text side by side, then test on mobile and with a keyboard. We also review the error flows of existing forms with the same checklist.

If you suspect your quote, contact, or checkout form is losing visitors, reach out through our web design page for a proposal that sets the scope and timeline. That way, your form rests on tested rules instead of guesswork.