Comparison file · feedback
Toast vs Alert vs Notification vs Banner vs Callout vs Badge vs Progress Indicator
Choose a message channel based on urgency, persistence, scope, and required action.
Run the diagnosisCommon search decision
Toast vs Banner: decide by message lifetime and scope
A Toast reports a recent event without blocking work and may disappear after users have time to perceive it. A Banner keeps a condition or announcement visible while it remains relevant to the page or site.
Choose a Toast
Use it for short-lived confirmation or status feedback when users can continue their current task.
Choose a Banner
Use it for a broad, persistent condition or announcement that users may need to notice before it stops applying.
Fast decision
Start with the behavior that changes the build
Toast
If information must persist or be revisited, use Notification or Banner instead.
Open field note ↗Alert
An ARIA alert is a semantic behavior, not every red box or every notification container.
Open field note ↗Notification
Notification is a channel and lifecycle concept, not a single visual shape.
Open field note ↗Banner
Do not confuse a visual banner message with the ARIA banner landmark for site-level header content.
Open field note ↗Callout
A Callout is authored into the content flow; use Alert for dynamically announced urgency and Banner for a page- or site-wide condition.
Open field note ↗Badge
A badge communicates a state attached to another element. Do not use it as a standalone button or a primary content label.
Open field note ↗Progress Indicator
Distinguish a determinate progress bar (known percentage) from an indeterminate spinner (unknown duration). Choose based on whether you can calculate the completion ratio.
Open field note ↗Behavior matrix
Compare contracts, not silhouettes
| Decision | Toast | Alert | Notification | Banner | Callout | Badge | Progress Indicator |
|---|---|---|---|---|---|---|---|
| Persistence | Usually temporary and not the only record of important information. | Long enough to perceive; often remains until the condition changes. | May remain until read, dismissed, archived, or resolved. | Persists while the page-level condition matters. | Remains visible while the surrounding content is available. | Persists as long as the associated condition or status applies. | Temporary — lasts only for the duration of the task. |
| Focus | Does not steal focus; any action must remain keyboard reachable. | Does not move focus. | Does not steal focus when delivered; actions are available when users open it. | Does not steal focus; actions enter normal focus order. | Does not move or receive focus unless it contains an ordinary link or control. | Badges are not focusable unless they contain a dismiss or action control. | Progress elements do not steal focus; indeterminate spinners should announce their state via a live region. |
| Required action | At most a small optional action; never a required workflow. | Primarily a message; required response belongs in an alert dialog or normal task flow. | May include durable actions or navigation to details. | May contain one or two clear actions related to the message. | Primarily explanatory content with an optional relevant link, not a required workflow. | Primarily informational; may include optional dismiss or click-to-navigate behavior. | Usually informational; optionally includes a cancel button for user-initiated tasks. |
| Scope | Recent event or local condition. | Recent event or local condition. | User or system event channel. | Page or site condition. | Recent event or local condition. | Recent event or local condition. | Recent event or local condition. |
| Placement | Consistent viewport region, often a stack near an edge. | Near the relevant content or in an announced status region. | Inline, in a notification center, or in a managed message region. | Prominent horizontal region near the top of the relevant scope. | Inside the content flow, directly beside the paragraph, form, or section it qualifies. | Adjacent to or overlaid on the associated element. | Inline near the task, or in a shared status region. |
Discriminating questions
Ask only what changes the result
- May the message disappear automatically without losing required information?Yes / No
- Does the message apply to the whole page rather than one recent action?Yes / No
- Should users be able to revisit or manage the message later?Yes / No
Implementation consequences
Turn the comparison into a build decision
The final choice must explain both the selected contract and the alternatives it excludes.
Name the task
Choose a message channel based on urgency, persistence, scope, and required action. Write the user goal before choosing any component from a library.
Freeze the decisive dimensions
For this group, compare Persistence, Focus, Required action, Scope, Placement. Do not allow visual similarity to replace those requirements.
State the exclusion
Record why the closest rejected pattern fails. That reason helps a coding agent avoid silently substituting a familiar but incompatible component.
Verify the behavior
Open the selected pattern reference, copy its acceptance checks, and test focus, keyboard, dismissal, placement, content, and mobile behavior in the real interface.
Frequently asked questions
Toast vs Alert vs Notification vs Banner vs Callout vs Badge vs Progress Indicator questions
Direct answers based on the reviewed behavior contract above.
What is the main difference between Toast, Alert, Notification, Banner, Callout, Badge, Progress Indicator?
Choose a message channel based on urgency, persistence, scope, and required action. The decisive dimensions on this page are Persistence, Focus, Required action, Scope, Placement. Read each column as a behavior contract, not as a visual style recommendation.
How do I choose among Toast, Alert, Notification, Banner, Callout, Badge, Progress Indicator?
Begin with the required user task, then answer the discriminating questions above. Choose the pattern whose purpose and behavior match the evidence, and explicitly reject alternatives whose focus, input, modality, persistence, or structural contract would break the task.
Can two of these terms apply to the same interface?
Sometimes. This taxonomy includes semantic patterns, composite patterns, presentation forms, behavior variants, message channels, and generic behavior labels. A presentation term and a semantic contract can coexist, so specify each required property instead of forcing every term into a flat either-or choice.
How should I verify the final implementation?
Open the selected pattern reference and run its observable checks. At minimum, confirm the configured trigger, dismissal, focus, keyboard behavior, interactive content, placement, and mobile adaptation. Also verify the linked official or first-party source against the library you ship.