message channel · Feedback and notices
Toast
A brief, non-blocking message about a recent event that may disappear after users have enough time to perceive it.
Decisive boundary
If information must persist or be revisited, use Notification or Banner instead.
Definition and intent
What is a Toast UI pattern?
Use the behavior, not the silhouette
A brief, non-blocking message about a recent event that may disappear after users have enough time to perceive it. The term is used here as a message channel whose timing, persistence, urgency, and actions must be specified. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Confirm a recent event without interrupting the current task. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Toast, the boundary is: If information must persist or be revisited, use Notification or Banner instead.
Do not implement it as Alert for semantically urgent live messages and Banner for persistent page-level conditions. If those requirements describe the real task better, use the related pattern page or the full Feedback and notices comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Confirm a recent event without interrupting the current task.
Define opening and closing
A completed action or system event. Optional close, timeout, or replacement; timing pauses on hover or focus when supported.
Specify access behavior
Does not steal focus; any action must remain keyboard reachable. Users can reach actions through a predictable shortcut or focus path and dismiss when offered.
Reject the near miss
Alert for semantically urgent live messages and Banner for persistent page-level conditions.
Behavior contract
What must survive the build
- trigger
- A completed action or system event.
- dismissal
- Optional close, timeout, or replacement; timing pauses on hover or focus when supported.
- modality
- Non-modal.
- focus
- Does not steal focus; any action must remain keyboard reachable.
- keyboard
- Users can reach actions through a predictable shortcut or focus path and dismiss when offered.
- interactive
- At most a small optional action; never a required workflow.
- persistence
- Usually temporary and not the only record of important information.
- placement
- Consistent viewport region, often a stack near an edge.
- mobile
- Avoid covering primary controls and respect safe areas.
Failure modes
Common wrong builds
- Putting required actions in an auto-expiring toast.
- Stealing focus.
- Showing multiple overlapping stacks.
Observable checks
Verify the result
- The message is not the only record of important data.
- It does not steal focus.
- Timing pauses when users interact.
- Actions are optional and keyboard reachable.
- It does not cover critical mobile controls.
Coding-agent handoff
Implementation brief template
Pattern: Toast Purpose: Confirm a recent event without interrupting the current task. Trigger: A completed action or system event. Dismissal behavior: Optional close, timeout, or replacement; timing pauses on hover or focus when supported. Modality: Non-modal. Focus behavior: Does not steal focus; any action must remain keyboard reachable. Keyboard behavior: Users can reach actions through a predictable shortcut or focus path and dismiss when offered. Interactive content: At most a small optional action; never a required workflow. Placement: Consistent viewport region, often a stack near an edge. Mobile behavior: Avoid covering primary controls and respect safe areas. Do not implement as: Alert for semantically urgent live messages and Banner for persistent page-level conditions. Acceptance checks: - The message is not the only record of important data. - It does not steal focus. - Timing pauses when users interact. - Actions are optional and keyboard reachable. - It does not cover critical mobile controls.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Toast UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Toast in web UI?
A brief, non-blocking message about a recent event that may disappear after users have enough time to perceive it. In this reference set it is a message channel whose timing, persistence, urgency, and actions must be specified.
When should I use a Toast?
Confirm a recent event without interrupting the current task. The decisive boundary to confirm is this: If information must persist or be revisited, use Notification or Banner instead.
What keyboard and focus behavior does a Toast need?
Users can reach actions through a predictable shortcut or focus path and dismiss when offered. Does not steal focus; any action must remain keyboard reachable. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Toast behave on mobile?
Avoid covering primary controls and respect safe areas. Its modality is a separate requirement: Non-modal.
How do I verify a Toast implementation?
Start with observable checks: The message is not the only record of important data. It does not steal focus. Timing pauses when users interact. Then verify the remaining checks and compare the result with the linked source guidance.