A toast is a message that assumes it will not be read. That assumption is the whole design constraint: it appears away from where the reader is looking, it leaves on a timer, and it cannot be retrieved. Anything the reader must see, must act on, or might want later does not belong in one.
33 public components on 21st have "toast" in the name, 29 say "notification" and 51 say "alert". Three different jobs, and the mismatch between them is the most common bug in this category.
Toast: something happened, carry on
Transient confirmation of something the reader just did. "Copied." "Saved." "Message sent."
Sonner by shadcn is the default answer, described by its author as an opinionated toast component for React, and it is the one shadcn/ui ships. Toast by Arunachalam is a styled system built on top of Sonner. Save Changes Toast by yadwinder is the specific variant that appears when a form has unsaved edits, which is a toast with a job rather than a message.
Google Drive Uploader Toast by Suraj Gaud is the progress case: a toast that stays because the operation has not finished, and reports as it goes.
The rules that make a toast work: bottom-right or top-centre, one position for the whole app; four to six seconds for a plain confirmation; stack rather than replace, and cap the stack at three; pause the timer on hover and on focus. And never put the only copy of information in one - if a toast says an export is ready, the export must also be somewhere the reader can find it in a minute.
Alert: something is wrong, here
An alert is inline and it stays. Alert by sean0205 is the standard shape.
The rule: an error belongs next to the thing that caused it. A form that fails validation and reports it in a toast at the other corner of the screen has told the reader something is wrong and hidden where. Toast for success, inline for failure, is a good default and roughly the opposite of what most apps ship.
Notification: something happened while you were away
A list with history. Notifications Menu by Ahmed Mayara, Notification Popover by Chetan Verma and Vercel Notification Popover by Patrick Xin are the bell-and-panel pattern. Notifications Filter by Ruixen UI adds the part that matters once there are more than a dozen: filtering by kind.
A notification centre is a data problem in a popover's clothing. Read and unread state has to survive a reload, the unread count has to be accurate or it becomes wallpaper, and "mark all as read" is not optional.
Announcing it to someone who cannot see it
This is where toasts fail most often, and it is a two-line fix.
A toast that appears in a corner is invisible to a screen reader unless it is inside a live region. Put the toast container in the DOM at page load - empty, not conditionally mounted - and give it aria-live. Use polite for confirmations, so the announcement waits for a pause in whatever is being read, and assertive only for errors that genuinely interrupt.
Two traps. A region that is added to the DOM at the same moment as its content usually announces nothing, because there was no region to observe; the container must already exist. And a toast with a button inside it needs role="alertdialog" and real focus management, or the keyboard user never reaches the Undo before it disappears - which is the strongest argument for giving destructive actions an inline confirmation instead of a five-second window.
Timing, honestly
The default of "a few seconds" is a guess that is wrong in both directions. WCAG's timing guidance is explicit that content which disappears on a timer needs a way to extend or dismiss it, unless it is truly incidental. In practice:
Three to four seconds for a confirmation with no action. "Copied" needs no more.
Six to ten seconds for anything with a button in it, and pause on hover, focus and keyboard interaction. An Undo that vanishes while the reader is moving the mouse toward it is worse than no Undo.
No timer at all for errors, and for progress that is still running. An error that removes itself is an error nobody can read twice.
Where else to look
The honest list of alternatives, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| Sonner | Stacking, swipe to dismiss, promise toasts, sensible defaults | Its own look, which you will end up theming |
| shadcn/ui | Sonner already wired, plus Alert for the inline case | Two components, no notification centre |
| Radix Toast | The behaviour and the live region when you own the styling | More wiring than Sonner for the same result |
| 21st | Notification centres, progress toasts and the styled systems | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue. The 21st MCP covers the same ground without leaving the editor: ask Claude, Cursor or Codex for a toast, get the previews inline, and let the agent write the file.
Browse notification components →
Frequently asked
- How long should a toast stay on screen?
- Three to four seconds for a plain confirmation, six to ten for anything with a button in it, and no timer at all for errors or for progress that is still running. Pause the timer on hover, on focus and on keyboard interaction. An Undo that vanishes while the reader is reaching for it is worse than no Undo.
- Should errors be shown in a toast?
- Usually not. An error belongs next to the thing that caused it, because a toast in the opposite corner tells the reader something is wrong and hides where. Toast for success, inline for failure, is a better default than what most apps ship.
- How do you make toasts accessible to screen readers?
- Put the toast container in the DOM at page load, empty rather than conditionally mounted, and give it aria-live: polite for confirmations, assertive only for interrupting errors. A live region created at the same moment as its content usually announces nothing, because there was no region to observe. A toast containing a button needs role="alertdialog" and real focus management.
- What is the difference between a toast and a notification centre?
- History. A toast is transient and unrecoverable, so it can never hold the only copy of anything. A notification centre is a list with read and unread state that survives a reload, an accurate unread count, and a way to mark everything read. If the reader might want the message in a minute, it needs the second one.