A toast notification, or simply a toast, is a small, temporary message that appears over the interface, usually at the bottom or a top corner of the screen, to give brief feedback about an action or system event and then disappears on its own. In UI design it is the standard pattern for non-blocking feedback: the user is informed without having to stop, click or dismiss anything.
The name comes from the way the message pops up like bread from a toaster. Typical toasts say “Message sent”, “Changes saved” or “Connection lost, retrying”. They belong to the family of feedback components together with banners, inline messages and modal dialogs, and the main design challenge is deciding which information is safe to show briefly and which needs a more persistent form.
Anatomy and behavior of a toast
A toast is built from a few fixed parts: a container, a short message, an optional status icon and an optional single action such as Undo or View. It sits in an overlay layer above the page content, does not take focus and does not block interaction with the rest of the screen.
The table below lists the main anatomical parts and common guidance for each.
| Part | Purpose | Common guidance |
|---|---|---|
| Container | Groups and elevates the message | Rounded box with shadow, high contrast |
| Message text | States what happened | One line, ideally under about 60 characters |
| Status icon | Signals success, info, warning or error | Never the only carrier of meaning |
| Action button | Offers one quick follow-up | One action at most, such as Undo |
| Close control | Lets users dismiss early | Required when the toast has an action |
A toast follows a short lifecycle: it enters with a brief animation, stays visible for a set duration, pauses its timer while hovered or focused, and exits. When several toasts arrive together, they are either stacked with a limit of about three visible at once, or queued so that each appears after the previous one leaves.
Timing, position and stacking parameters
Display duration is the most consequential parameter of a toast. A common rule of thumb is 4 to 6 seconds for short messages, or roughly one second per four to five words plus a base of two seconds. Toasts that contain an action need longer durations or no auto-dismiss, because users must notice, read and react.
| Parameter | Typical range | What it affects |
|---|---|---|
| Auto-dismiss time | 4-10 seconds | Whether users can read the message |
| Enter animation | 150-300 ms | Noticeability without distraction |
| Visible stack limit | 1-3 toasts | Clutter and covered content |
| Maximum width | About 320-560 px | Line length and readability |
| Screen position | Bottom center or a corner | Proximity to the triggering action |
Position should be consistent across the product. Bottom placement suits mobile apps because it stays near the thumb and does not cover the header. Desktop products often use the top-right or bottom-right corner. The toast must never cover primary navigation, the floating action button or the control that triggered it.
Toast compared with other feedback patterns
Choosing a toast is a decision about urgency and persistence. A toast is right for low-urgency, self-explanatory confirmations. A modal dialog is right when the user must decide something before continuing. A banner suits persistent, page-level conditions, and an inline message suits feedback about a specific field or element.
| Pattern | Blocks the user | Persistence | Best for |
|---|---|---|---|
| Toast notification | No | Seconds, auto-dismiss | Confirmations, light status updates |
| Snackbar | No | Seconds, often with action | Undoable actions in mobile apps |
| Banner | No | Until resolved or dismissed | Account, billing or system conditions |
| Inline message | No | While the condition exists | Form validation, field-level errors |
| Modal dialog | Yes | Until the user responds | Destructive or irreversible decisions |
In many design systems the terms toast and snackbar are used interchangeably. Where they are distinguished, the snackbar usually appears at the bottom, contains at most one action and is tied to the current screen, whereas the toast is purely informational and may come from background events such as a completed upload.
Accessibility requirements for toasts
Toasts are a frequent accessibility failure because they appear outside the user’s focus and vanish on a timer. Screen reader users learn about them only if the container is a live region, typically with role="status" or aria-live="polite" for routine messages and role="alert" only for genuinely urgent errors.
- Timing: WCAG success criterion 2.2.1 requires that users can extend or turn off time limits, so toasts with actions should not disappear while the user needs them.
- Focus: a toast should not steal focus; any action it offers must remain reachable by keyboard or be available elsewhere.
- Contrast: text and icons need at least 4.5:1 contrast against the toast background.
- Motion: enter and exit animations should respect the reduced motion preference.
Common mistakes with toast notifications
Most toast problems come from using the pattern for information that is too important or too long. A message that the user must not miss belongs in a persistent form, not in a component that disappears by design.
| Problem | Consequence | Better approach |
|---|---|---|
| Critical error in a toast | Users miss data loss or failure | Inline error or modal dialog |
| Long multi-line text | Unreadable before it disappears | Shorten text or link to details |
| Several actions in one toast | Rushed, error-prone choices | Single action or a dedicated screen |
| Toast for every click | Notification fatigue | Reserve toasts for meaningful events |
| Stacked toasts covering content | Blocked controls and clutter | Queue messages, limit the stack |
In plain words
A toast notification is a small message that pops up briefly. It tells you that something happened, for example that a photo was uploaded. Then it fades away by itself. You do not have to click it. It does not stop what you are doing.
Think of a shop assistant who quietly confirms your order as you walk past. Nobody stops you to sign a form. The rule is simple: a toast should only carry news you can safely miss. Anything serious deserves a message that stays on the screen.
A real-world example
An email web app lets users archive messages with one click. The design team shows a toast at the bottom left reading “Conversation archived” with an Undo action. Because the toast contains an action, they set the duration to 8 seconds, pause the timer on hover and keyboard focus, and announce the message through a polite live region.
Usability tests reveal that some users archive several emails in a row and the toasts pile up over the folder list. The team changes the behavior so that each new toast replaces the previous one and its Undo restores all recent archives together. Accidental archiving complaints to support fall noticeably, and the inbox stays uncluttered during fast triage.