Toast vs banner vs inline
A toast confirms something that already finished and leaves on its own. A banner describes a condition that's still true after a reload. An inline error belongs to one exact field and clears once that field is fixed. Ask where the problem lives, and the answer picks itself.
The rule
Each of these three answers a different question about a message. Does it still matter after a reload? A toast doesn't, so it can leave on a timer with nothing lost. A banner does, so it stays exactly as long as the condition behind it does. Does the problem belong to the whole screen or to one field? A banner and a toast both speak for the page or a section of it. An inline error speaks for exactly one field, and it clears the moment that field becomes valid, not on a timer and not because a wider condition changed. Ask those two questions, in that order, and the right one is rarely in doubt.
Side by side
| Toast | Banner | Inline error | |
|---|---|---|---|
| Survives a reload | No, gone once its timer runs out | Yes, until the condition changes | Yes, until the field is fixed |
| Scope | Floats above the whole screen | The page or a section of it | One specific field |
| Appears | After an action finishes | On load, or after an action | After a field loses focus, or a form submits |
| Goes away | On its own, plus an optional close button | Only once the condition is resolved, if at all | Once the value in that field is valid |
| Live region | role="status" or role="alert" | role="status" or role="alert" | role="alert" on the message, aria-invalid on the field |
| Common home | A corner of the screen | The top of a page or section | Directly under the field it describes |
Gmail's undo-send message is a toast: the archive already happened, and the message is gone in a few seconds either way. Stripe's dashboard shows a persistent banner while an account is in restricted mode, because the restriction doesn't lift on its own. Any checkout form's card-number field puts "Card number is invalid" directly under the field, because the problem belongs to that one input and nowhere else on the page.
Use a toast when
- Something just finished and the person needs a brief confirmation, not a decision
- The message still makes sense once the screen that triggered it has moved on
- It's fine if someone looks away and misses it entirely
- At most one thing needs undoing, and the undo fits in a single button
Use a banner when
- The condition persists until something changes it: an unpaid invoice, an outage, an unverified email
- The message applies to the whole page or section, not one field
- It should still be there on a reload, not just for this one visit
Use an inline error when
- The problem belongs to exactly one field, not the whole form
- Fixing that one field is enough to clear the message
- The message needs to sit exactly where the fix happens, not floating elsewhere on the page
Where people get it wrong
The most common mix-up sends a one-time confirmation into a banner. "Changes saved" doesn't describe an ongoing condition, so pinning it to the top of the page after the save already finished reads like something is still wrong when nothing is.
The reverse costs more. A failed payment or an expired trial that surfaces as a toast disappears in a few seconds, but the problem it describes is still there on the next visit. Nobody reading a toast has time to act on it before it's gone, and nobody returning to the page the next day remembers it either.
A field-level problem is the third miss, when it lands in a toast or a banner instead of next to the field itself. "Fix the errors below" at the top of a twenty-field form makes someone hunt for the one that actually failed, when an inline error under the exact field would have pointed at it directly.
The reload test settles most of it. Refresh the page. If the message would still make sense, it was never a toast. If it belongs to one field rather than the whole screen, it was never a banner either.
Last reviewed 30 JUL 2026