Toast
A brief confirmation that disappears, which makes it unsuitable for anything the user must act on.
Definition
A toast is a transient message confirming that something happened. Because it vanishes, it can only carry information the user does not need to keep or act on later.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Confirming a completed action.
- Offering undo alongside a persistent alternative.
Common mistakes
- Errors delivered by toast.
- Undo available only in a toast.
- Assertive announcements for routine confirmations.
- Toasts covering navigation on mobile.
Rules
- Confirmations only. Errors that need action belong inline, next to their cause.
- Duration proportional to length, with a minimum of about four seconds and pause on hover or focus.
- If a toast contains an action such as undo, it must not disappear before the action can realistically be taken, and the action must also exist elsewhere.
- Announce through a polite live region. Assertive interrupts the screen reader and should be reserved for genuine urgency.
- Stack a limited number and collapse the rest, rather than filling the screen.
- Position consistently, and away from the primary interactive area on mobile.
What may and may not live in a toast
| Content | Toast? | Why |
|---|---|---|
| Saved | Yes | Confirms something the reader just did, and is safe to miss |
| Deleted, with undo | Yes, if undo also exists elsewhere | The toast is the fast route, not the only one |
| A validation error | No | It belongs beside the field that caused it |
| A failed background job | No | It needs somewhere durable to be found |
| A permission request | No | It requires a decision, so it needs attention |
| Five toasts at once | No | Stack them, or say what happened in one message |
In practice
- i.
The undo nobody caught
TimingA four-second toast holding the only undo for a bulk delete disappeared while the reader was still reading the first line. Where undo matters, it has to survive somewhere the reader can return to.
- ii.
Announced, but not focused
Screen reader behaviourA toast should be announced through a polite live region without stealing focus, so it interrupts neither typing nor the reading order. Moving focus to it is a common and disorientating bug.
Commonly confused with
Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.
Alert and Inline Message
ComponentA persistent message rendered in the flow, next to the content or field it concerns.
Key difference
An alert stays in the layout beside the thing it is about. A toast floats, times out, and takes its message with it, so nothing a reader must act on belongs in one.
Use Toast when
- You are confirming something the reader just did.
- The message is safe to miss entirely.
- Any recovery it offers, such as Undo, also exists elsewhere.
Use Alert and Inline Message when
- The reader has to do something about it.
- The message explains a state that is still true.
- Missing it would leave the reader stuck or wrong.
Notifications
PatternThe policy and channels by which a product tells someone an event occurred.
Key difference
A toast is one delivery channel. Notifications are the whole system behind the event: what is worth telling anyone, how urgent it is, and where it lives once the moment has passed.
Use Toast when
- The reader caused the event and is still looking at the screen.
- The message is safe to miss.
- Nothing needs to be retrievable afterwards.
Use Notifications when
- The event happened while the reader was elsewhere.
- You are deciding between inbox, badge, email and push.
- There has to be somewhere to catch up on what was missed.
Local chart
CMP·014 · Region III · Grid E2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Principles behind this
The reasoning this solution is an application of.
- User Control and FreedomHEUR·003 · Heuristic
- Visibility of System StatusHEUR·001 · Heuristic
- FeedbackPRIN·004 · Principle
Depends on
Get these right first, or this one will not hold.
- Status Messages and Live RegionsA11Y·009 · Accessibility
Often used with
These usually appear in the same screen or the same decision.
- Destructive ActionsPAT·009 · Pattern
- UndoPAT·022 · Pattern
Practical example
A worked decision where this was the deciding factor.
- Reducing Notification Volume Without Losing SignalCASE·007 · Case study
Related concept
Connected closely enough to change how you apply this.
- Error MessagesWRT·002 · UX writing
- Notification CopyWRT·013 · UX writing