Error Message Design

The live example above is plain HTML with Tailwind utility classes, so you can paste it into any Tailwind project. It uses type sizes text-sm (14px) and spacing mt-1.5 (6px), px-3 (12px), py-2 (8px), gap-1.5 (6px), constrained by max-w-sm. Everything sits on a 4px grid, which keeps rhythm consistent when you adapt it.

Colors use Tailwind's neutral stone scale so the pattern stays brand-agnostic. Swap stone-900 for your primary color on the main action, keep body text dark and check contrast after any change.

A new user fills in a signup form and types 'maya@studio' as her email. When she moves to the next field, a message appears right under the email: 'Enter an email like name@company.com', with an icon and a red border on the field. Her text stays in place, so she only needs to add '.co'.

She submits the form and the password does not meet the rules. A summary at the top lists the problem and links to the field, and focus moves to that summary so screen reader users hear it immediately. She fixes the password, the error disappears as soon as it is valid, and the form submits. When the server is briefly unavailable, a banner says the account could not be created yet and offers to try again, without clearing what she typed.

Signup and login forms need clear errors for passwords, emails and existing accounts, without revealing security-sensitive details.

Checkout and payment flows must explain card declines and address problems precisely, because each error risks a lost sale.

Data-heavy tools show validation errors in tables and bulk imports, often summarizing errors per row.

Inline errors usually sit directly below the field in a red that passes contrast against the background (such as a deep red rather than a bright one), at 13 to 14px, with an icon. The field border changes to the error color and becomes slightly thicker. Error summaries at the top of forms use a tinted background, a heading and a list of links to each field.

On mobile, errors can be hidden by the keyboard. Scroll the first error into view, keep messages short, and avoid placing error text where it will be covered by the keyboard or sticky buttons.

Set aria-invalid="true" on invalid fields and connect messages with aria-describedby. On submit, show an error summary with links to each field and move focus to it. Use role="alert" for errors that appear without user focus moving.

In a design system, errors appear in several components: field error text, an error summary, a page-level alert and full-page error templates. Define a single error color that passes contrast, a shared icon, and copy guidelines, and build the field components so they handle aria-invalid and aria-describedby automatically.

Track which fields cause the most errors and how often users fail to submit. Frequent errors on the same field often mean the label, format or validation rules need to change.

Before shipping, run a short usability test with five or so people from your audience. Give them tasks rather than instructions and watch where they hesitate:

Good error messages follow a simple formula: what happened, why if helpful, and how to fix it. 'Enter a date in the future' is better than 'Invalid date'. Avoid blaming the user, technical jargon and humor in errors that cost users time or money.

If you use an AI UI generator such as Inspo AI, these prompts are a good starting point for exploring variations of this pattern:

Errors are closely related to forgot password flows, toast notifications and form design best practices.