Toast or inline error — where to show it so people actually fix it

The form didn't submit. You print "Please check your entries" — and now you choose: a pop-up panel in the corner, or a line under the field.

It feels like a matter of taste. It isn't. The choice decides whether the error gets fixed or the tab gets closed, because these two things do different jobs.

The short version, if you're in a hurry: if the person can fix it right now, put it by the field. If there's nothing to fix, a panel is fine.

What each one actually does

An inline error is tied to a place. It says not just "something's wrong" but "right here". It doesn't go anywhere, and stays on screen until the problem is solved.

A toast is a panel that appears over the interface and leaves on a timer. It's tied to nothing and, by design, doesn't hold attention.

The difference isn't "minor error versus major one". It's whether there's an action to take at a specific point on the screen.

Compared on what actually matters

Will it be noticed. Inline wins when it sits next to the field the person is already looking at. It loses on long forms: error at the top, button at the bottom, a screenful of scrolling in between. A toast is visible for the first few seconds, and only to whoever happened to be looking at that corner.

Can it be re-read. Inline, yes — a minute later if needed. A toast, no: gone is gone. For a ten-word message that settles it.

Is it clear what to fix. Inline answers by position alone. A toast has to spell it out — "The Phone field has an invalid format" — and the person still has to find that field by eye afterwards.

Accessibility. A field in error gets aria-invalid="true" and links its message via aria-describedby, so a screen reader reads the error together with the field when moving to it. A toast lives in a separate region with role="status", announced once, unattached to anything: heard it, now go looking. The standard is strict here — the error must be described in text and must identify the item it applies to. A red border alone doesn't count: colour isn't text.

Message length. Inline carries two lines plus a format hint. A toast can't exceed one short sentence, or nobody finishes reading.

Small screens. Inline stays with its field and survives scrolling. A toast often slides up from the bottom and covers the submit button — the exact target of the next tap.

Several errors at once. Inline shows all three simultaneously, each in place. A toast gives you either three panels in a row or one vague "Check the form".

Who should use what — the straight answer

Inline only:

• anything the person typed — email, phone, password, date;
• required fields left blank;
• a server-side validation error that maps to a specific field ("This email is already registered").

Toast only:

• the result of a background action: "File uploaded", "Report ready";
• an undo offer: "Task deleted — Undo";
• events the person didn't trigger: "Connection restored".

Both: when the whole submission failed — the server died, the network dropped. The panel reports the fact, and a line next to the button stays put: "Couldn't send — try again". This is precisely the case where a 500 response belongs to no field, yet silence isn't an option.

The mistake almost everyone makes

Showing the error as a toast and under the field and turning the border red. It feels "safer". In practice it's three messages about one problem: the person spends time working out whether there are three errors or one.

The rule is simple: one problem, one place. If you really want redundancy, duplicate the signal, not the text — the border draws attention, the text explains.

The second common miss is showing an inline error while the person is still typing. "Invalid email format" on the third character reads as nagging. Validate on blur or on submit — but clear the error the moment they start editing the field.

How to write the message itself

The standard separates two levels: reporting the error, and suggesting the fix. "Invalid email" is level one. "Looks like the @ is missing — for example [email protected]" covers both, and costs exactly one extra clause.

Three things to avoid: the word "invalid" (nobody talks like that), bare error codes, and phrasing like "you entered it wrong" — they're already unhappy. For decoding technical messages, see how to read an error message.

Can I avoid toasts entirely?

Yes. A form that writes errors by its fields and shows the result in place of the button needs no panels at all. For a contact form that's the sturdiest option: "Sent" appears exactly where the button just was.

Is a red border enough?

No. Colour isn't read by screen readers and isn't distinguishable for some users. The border supplements the text; it never replaces it.

Where do I put the error when there's no field?

File uploads, for instance — attach the message to the drop area itself. Even without an input the principle holds: text next to the element, not in the corner of the screen.