Display form-field error messages when the user enters something that’s not quite right, or when the system does something unexpected. Our goal: show just enough information to help the customer address the problem and keep going.


When the stuff the user puts into a form isn’t quite right, we show the user an error message. We call these validation error messages, because the system figured out that the content entered isn’t valid.

We support three different validation types:

1. Real-time field error validation

The field error validation occurs when the user is completing a form either when the user has stopped typing in the input field or when the user has clicked or tabbed away from the field or control.

Use real-time field error validation if:

  • The user entered information that does not meet the requirements of the field or form (for examples, letters in a numerical field)
  • The user skipped a required field

2. Server-side field error validation

If the user submits a form and the system detects an error, the form refreshes and an error appears in-line. This in-line callout might also appear with a page-level message that cannot be dismissed until the user takes action.

Use server-side field error validation if a problem occurs after the user submits a form.

3. Asynchronous field error validation

This occurs when the system sends an error after an email bounces or after some aspect of a transaction fails. This type of error is displayed globally, as the user might be working in a different part of the product when the system detects the error.

Use asynchronous field error validation if:

  • There is a delay between the user action and the error (for example, an email doesn’t get through because of delivery error)
  • The error is at a global level (for example, the user’s credit card information is incorrect)

Appearance and behavior

Each validation type differs in appearance:

1. Real-time field error validation

  • To draw immediate attention to the error, a red error icon displays next to a red field title. The form field border color becomes red
  • A standard tooltip is triggered on focus of the field, or on hover of the icon
  • The user can dismiss the tooltip by clicking outside the field
  • When the user corrects the error, the tooltip and error state go away




2. Server-side field error validation

If your form is simple, short, and fits in a single window (like a sign-up form) use only in-line callouts (see real-time validation).

Complex forms

If the error is associated with fields within the page, in-line error messaging appears at the field or control level and cannot be dismissed. In this case, the page-level error message displays a generic message about the error state (such as “The information you entered doesn’t quite fit. Check the info that’s highlighted in the form.”) and relies on in-line error messaging to communicate the specifics of the error. These page-level messages appear in red with a red outline, icon, and title.

Refer to the page messages pattern for warning, alerts, and information messaging.


3. Asynchronous error validation

When asynchronous errors are present, the user can still continue using the application normally. These errors persist at the top of the page as the user navigates through the application, and they push the page contents down until the user dismisses them.

You can display multiple asynchronous errors and alerts together in the global error message. In such a case, the message needs to indicate the total number of errors and alerts and lets the user expand the global area to reveal them.

The corresponding messages appear in-line as an Overlay on the existing page contents. Within the Overlay, messages are grouped by type. Additionally, Asynchronous Errors are given a higher priority and appear first in the list before Passive Alerts. Within each type, messages appear in reverse chronological order. Users may dismiss each error or alert individually, or dismiss them all by clicking the “Dismiss All” within the Global Error Message.

Refer to the page messages pattern for warning, alerts, and information messaging.


Content guidelines for error messages

Keep form-field error messages short, simple, and straightforward. When the error message is a complete sentence, end it with a period. Example: “Enter your email address.”

For more information about writing page-level messages, including page-level errors, see the page messages pattern.


Responsive behavior

On mobile devices, form-field error messages appear below the field at all times, while the field and label turn red. If the user hasn’t completed a required field, the field does not animate closed. Instead, it remains open in the error state, further emphasizing that something is missing.




  • Was this Helpful?