Ask a web developer and a Windows developer what a toast is and you will get two different answers.
Web apps, Android and Windows all use toasts to confirm small things, like a saved setting or an uploaded file. On a web page, the toast is a non-modal message that shows up at the edge of the screen, takes no focus, asks for no input and dismisses itself after a set time.
Windows sends an operating system notification instead. It stays in the Notification Center for 3 days by default (Microsoft Learn, Windows App SDK documentation, as of October 2026).
What Is a Toast Notification?
It appears at the edge of the screen, never takes focus, asks for no input and goes away after a set time. That non-modal behavior is the whole definition.
It is one of the lightest feedback patterns among the user interface components a product ships, far below a dialog in interruption level.
Android’s Toast reference describes it as a floating view that never receives focus, and gives the volume control and a “settings saved” message as its two typical cases.
Most toasts show the visible result of something the user just did, like saving a setting or uploading a file. Some report a status change the user never started, such as a finished background sync. Microsoft’s Azure DevOps component documentation says a toast is generally the result of a direct user interaction, so system-event toasts deserve a second look before they ship.
Windows calls the same feature something else. As of October 2026, its Windows App SDK documentation calls it an app notification and says the term “toast notification” will be phased out over time.
Anything the user must read or act on belongs somewhere that stays on screen.
What Does a Toast Notification Contain?

Not much. The text runs one or two lines, an icon with a severity style is optional, and there is room for one action button at most.
Message text
Apps targeting Android 12 (API level 31) or newer get toasts limited to two lines, according to the Android Toast reference.
Material Design allows the same two lines for a mobile snackbar label, while Microsoft’s Azure DevOps guidance asks for a single line wherever possible.
The text names the outcome, not the process.
- Settings saved
- File uploaded
- Link copied
Severity and icon
Success means an action finished and error means it failed. A warning covers a risk the user can still work around, and info is for a neutral status change.
Design systems disagree on icons. Material Design’s snackbar guidance tells designers to skip them, while react-toastify 11.1.0 ships built-in icons for info, success, warning and error.
Either way, color cannot be the only signal. Pair it with an icon or a word, and check the text against the toast background for enough color contrast, because the toast lands on top of whatever the page happens to show.
Action button
A toast gets one action, and it should not be labeled “Dismiss”.
The Azure DevOps toast takes a single call to action and bans “Dismiss” and “Cancel” as its label. Material Design calls a dismiss action on a self-closing snackbar unnecessary.
Canva’s app guidelines go further. Its toast carries a message and an “Ok” button, and no other interactive components.
Undo is the label that earns its place. A button on a message that disappears in a few seconds is easy to miss, which is why a toast with an action starts to behave like a snackbar.
How Long Does a Toast Stay on Screen, and Where Does It Appear?
On the web, a toast typically stays visible for roughly 4 to 10 seconds and sits in a corner or along the bottom edge of the screen. Android’s built-in Toast is shorter, at about 2 or 3.5 seconds.
Material Design gives its snackbars a minimum of four seconds and a maximum of ten, and react-toastify closes a toast after 5000 ms unless told otherwise.
Duration
Android offers two fixed choices, LENGTH_SHORT (the default) and LENGTH_LONG. In the Android framework source these come to about 2 and 3.5 seconds, but the Toast reference adds that either value can be user-definable, so the exact seconds vary by device.
Web libraries take milliseconds instead. In react-toastify the autoClose option accepts a delay or false, and false keeps the toast open until someone closes it.
The accessibility limit matters more than the number. W3C’s Understanding document for WCAG 2.2 criterion 2.2.1 uses a toast as an example of a time limit that does not apply: an email notice that vanishes after 5 seconds passes, because the user can see new mail in the inbox anyway.
So auto-dismiss is fine when the same information also lives somewhere else. When the toast is the only place the message appears, it needs a time control.
In that second case, users must be able to turn the limit off, adjust it to at least ten times the default, or extend it.
Position
Defaults vary by platform, and the Windows sources do not agree with each other.
- react-toastify sits top-right by default, with six positions available.
- Bootstrap has no default. The docs leave placement to the developer.
- Material Design puts the snackbar at the bottom of the interface.
- Windows shows it bottom-right in the current Windows App SDK documentation and upper-right in the older Windows Runtime documentation.
Web toasts are pinned to the viewport, so a container can end up on top of a cookie bar, a chat widget or a floating action button. Keep it away from anything the user needs to reach.
On Android, placement is increasingly the system’s call. For apps targeting API level 30 or higher, text toasts are no longer rendered by the app, and the reference says setGravity is a no-op on text toasts at that level.
Stacking and queues
Design systems show one toast at a time. Azure DevOps fades the older toast out quickly so the newer one can appear, and Canva’s guidelines limit the toast to one message.
Libraries default the other way. Sonner shows up to 3 toasts at once and expands the pile on hover, react-toastify offers limit and stacked options, and Bootstrap stacks toasts vertically inside a container.
Three is a ceiling, not a target. If a workflow keeps filling it, the fix is one summary message (“4 files uploaded”), not a longer queue.
How Does a Toast Differ From a Snackbar, Modal, Banner and Push Notification?
The toast is the passive one, and it dismisses itself. A snackbar adds a single action. A modal blocks the interface until the user answers, a banner hangs around until someone dismisses it, and a push notification comes from the system, outside the app.
| Pattern | Dismissal | Interaction | Typical use |
|---|---|---|---|
| Toast | Automatic | None to one action | “Settings saved” |
| Snackbar | Automatic, swipe on some platforms | One optional action | “Message deleted. Undo” |
| Banner | Stays until dismissed | Optional | Account or system status |
| Modal | User must respond | Required decision | Destructive or blocking choices |
| Push notification | Cleared from the system tray | Tap opens the app | Messages outside the app |
Toast vs snackbar
Android’s Toast reference says Snackbars are preferred for brief messages while the app is in the foreground, and Material Design gives them an optional action.
Dismissal is where sources split. Material says snackbars disappear on their own after four to ten seconds. LogRocket’s guide defines a snackbar as a message that does not disappear automatically, and still calls a self-dismissing message with a non-critical action a toast.
The working rule that survives both is simple. No button, call it a toast. Once there is a button the user needs to reach, like Undo, it is a snackbar.
Toast vs modal
A toast never takes focus. A modal does, and it holds the interface until the user responds.
Material Design ranks dialogs as the highest-priority message and snackbars as low priority. Canva’s guidelines send anything that needs input into the app UI, because the toast cannot hold interactive components.
If the user cannot continue without answering, it is not a toast.
Toast vs banner and push notification
A banner stays until the user dismisses it, which suits status the user has to keep seeing. A push notification is delivered by the operating system, reaches users outside the app and waits in the notification tray.
Windows blurs that last line. Its app notifications appear in a transient window, stay in the Notification Center, and can arrive while the user is not in the app at all.
That makes a Windows toast closer to a push notification than to an in-page web toast.
When Should You Use a Toast, and When Is It the Wrong Choice?
Use a toast when the message is low stakes and the user loses nothing by missing it. If a later step depends on rereading it, pick something else. An inline message, a banner or a dialog all do better for the rest.
A quick test before you ship one
Start by asking whether the user needs to act. A required action calls for a dialog or an inline control.
Then ask whether missing the message causes harm. Lost work, a failed payment or a silent error means the message has to stay.
Last, will the user need to read it again? If so, it goes where it persists, such as a banner or a notification center.
A toast only makes sense when every answer is no. One yes and the message moves somewhere else.
GitHub’s Primer design system goes further and recommends against toasts altogether, pointing teams to banners, dialogs and inline validation instead.
Messages that should never be a toast
Red Hat’s design system clears a timed toast after about eight seconds, and its own guidance says a critical error should never live only inside one.
- Blocking errors that stop the task
- Form validation, which belongs inline, next to the field
- Results with several parts or steps
- Updates after a long-running task
Beyond the WCAG issues, Primer lists usability problems too, including distraction while multitasking and banner blindness, plus trouble for people using screen magnification.
Primer also warns that toasts can cover primary actions such as a submit button, especially when they stack. Red Hat’s guidance repeats that warning, along with the risk that a timed toast expires unseen when the user switches tabs.
How Do Toast Notifications Work on Android, Windows and the Web?
Android and Windows ship native toast APIs. HTML has none, as Adobe’s React Aria documentation puts it, so every web toast comes from a library or custom code.
Android
On Android you build a text toast with makeText() and display it with show(). That is the whole API for the simple case.
addCallback reports when a toast is shown or hidden, but it stays silent if the system blocks the toast. setView is deprecated, and apps targeting Android 11 or newer get no custom toast views from the background. Toasts sent from the background are also rate limited, so avoid firing them in quick succession.
Treat an Android toast as best-effort feedback, never as the only record of an event.
Windows
Windows adds housekeeping the other platforms lack.
- Subscribe to NotificationInvoked before calling Register, or a new process launches to handle the click.
- Assign Tag and Group values when sending, so related notifications can be removed from the Notification Center later.
- Set Expiration for time-bound content, such as a calendar reminder that should end with the event.
Notifications for elevated (admin) apps are a documented dead end, since they are not supported in the Windows App SDK, as of October 2026.
Web libraries
- Bootstrap bundles a toast component with the CSS framework.
- Material UI has a Snackbar component for React.
- react-toastify gives you a ToastContainer plus a toast() call.
- Sonner needs one Toaster component, and then toast() works from anywhere in the app.
- Toastr is a jQuery-based library for non-blocking notifications.
For projects already on Bootstrap, the bundled toast is the lowest-effort choice.
Toastr is the odd one out. It is a JavaScript library that requires jQuery, so it only makes sense where jQuery is already loaded.
A few defaults are worth knowing, all as of October 2026.
- In the Windows App SDK, a notification stays in the Notification Center for 3 days by default, and 3 days is the maximum (Microsoft Learn).
- Material UI’s Snackbar has autoHideDuration set to null by default, so nothing hides until a value is set (MUI API docs).
- Toastr’s extendedTimeOut defaults to 1000 ms, the time a toast lingers after the pointer leaves it (Toastr source).
- Bootstrap toasts hide automatically unless autohide is set to false (Bootstrap docs).
Are Toast Notifications Accessible?
Not by default. Writing in 2020, Adrian Roselli said few, and none he had found, of the existing toast-style patterns would pass a WCAG audit.
A toast can meet the standard, but only if someone builds the live region and the focus handling deliberately, and gets the timing right.
What WCAG 2.2 requires
The governing rule is success criterion 4.1.3, Status Messages, at Level AA. This web accessibility requirement says a status message must be programmatically determinable through a role or property, so assistive technology can present it without the message receiving focus (W3C Understanding document).
In practice, role=”status” gives a polite announcement and suits confirmations, while role=”alert” announces assertively and fits errors that need attention now.
A dialog that takes focus is out of scope for 4.1.3, because moving focus is a change of context, and the criterion covers only messages that are not. That is why the criterion treats a toast and a dialog as different cases.
Where the sources disagree
Primer’s blanket advice is to avoid toasts. It lists four primary WCAG criteria they risk violating (2.2.1 Timing Adjustable, 1.3.2 Meaningful Sequence, 2.1.1 Keyboard and 4.1.3 Status Messages), plus four secondary ones.
Others say they can be allowed with care. In a 2025 thread on the W3C WAI interest group list, Steve Green argued that 4.1.3 does not prohibit status messages, toasts included, from containing focusable components. It only requires that the information reach assistive technology without moving focus.
Other participants in the same thread held that automatically disappearing toasts conflict with 2.2.1. Both camps cite the same criteria and reach opposite verdicts.
Red Hat’s design system takes the middle path. Its toast is a polite status message that never interrupts, with a persistent option that keeps the message on screen until the user dismisses it.
How libraries announce toasts
Libraries do not agree on the role either.
| Library | ARIA behavior | Applies to |
|---|---|---|
| react-toastify | role=”alert”, changeable per container or per toast | Every toast |
| Toastr | aria-live polite for success and info, assertive for the rest | By toast type |
| Red Hat Design System | role=”status” with aria-live polite | Every toast |
react-toastify also adds a keyboard route: pressing alt+t focuses the first notification, and Tab then reaches its controls.
How to build an accessible toast
The gaps above close with a short build, centered on an ARIA live region that exists before any toast does.
- Render an empty live region when the page loads. Regions that appear together with their content are not reliably announced.
- Inject the message text into that region, with role=”status” for confirmations and role=”alert” for errors.
- Leave focus where it is. A toast that takes focus is no longer a status message.
- Give keyboard users a way in: a reachable close button, Esc to dismiss (Material UI reports escapeKeyDown as a close reason) and a shortcut such as react-toastify’s alt+t.
- Pause the timer on hover and focus. Toastr and Material UI (through resumeHideDuration) both build in a delay after interaction.
- Keep errors persistent, or move them inline.
Then test with a screen reader. An automated checker cannot hear a missed announcement.
Toast Notification FAQ
Why is it called a toast?
The usual explanation is the motion. The message pops up at the edge of the screen like bread from a toaster.
O’Reilly’s Universal Windows Apps book describes the term the same way.
Do Windows toasts play a sound?
Yes. Microsoft’s Windows Runtime toast documentation says a Windows toast comes with a sound that plays when it appears, which a tile update does not.
The Windows App SDK also supports custom audio on app notifications.
Can a toast include a link?
Usually not. Microsoft’s Azure DevOps toast guidance lists hyperlinks under what to leave out and allows a single action button instead.
A link also races the auto-dismiss timer, so the user can run out of time before reaching it.
Which toast library fits a React project?
Match the library to the stack. react-toastify and Sonner both work from one container component plus a toast() call, and a project already on Material UI has Snackbar.
For full control over announcements, Adobe’s React Aria offers headless toast hooks, with a landmark region labeled “Notifications” by default.
Can a server send a toast?
On Windows, yes. App notifications can be sent locally or from a cloud service through push, and they can be scheduled for a set time.
A web toast exists only while its page is open, so a server can trigger one only through code already running in that page.
Which Toast Notifications to Replace First
Replace first any toast that carries an error or a button the user must reach, and any toast that holds the only copy of a result. The order follows consequence: the cost of a missed message grows with what the message says.
- Errors that block the task, moved inline
- Toasts with an action button, made persistent
- One-time results, mirrored in a banner or notification center
Arithmetic on two cited sources explains the last step. Material Design’s four to ten second window, multiplied by the ten-times adjustment WCAG 2.2.1 asks for, comes to 40 to 100 seconds, so persistence beats a longer timer.
The cost is that a persistent message holds screen space until the user clears it, so the confirmations that remain toasts should stay low stakes.
The same audit applies to dialogs, banners and other accessible UI components in the product.
- How to Insert Image in Figma With Ease - November 3, 2026
- How to Download Figma Files Fast and Free - October 30, 2026
- Figma Keyboard Shortcuts That Will 10x Your Speed - October 25, 2026


