The case against toasts

Toasts are a weak form of feedback because they break a basic UX rule: the place where the user’s action happens should match the place where the confirmation appears. In practice, toasts often show up far from the user’s attention—typically in a corner—so people click something, wait, and then have to hunt for whether anything actually worked. A common example is YouTube’s “Save” flow: clicking a button triggers a modal in the center of the screen, but the confirmation arrives later as a small toast in the bottom-left corner. On a full screen, that mismatch is easy to miss; when the user has scrolled or the UI is visually busy, it can feel like the click did nothing.

The problem gets worse when toasts are delayed and when multiple actions overlap. In the YouTube scenario, the confirmation toast doesn’t appear immediately and there’s no clear loading indicator tied to the action. If the user changes a checkbox inside the modal, they may have to wait several seconds for the previous toast to disappear before the next one shows up. Rapid interactions—hovering, saving to a playlist, removing, adding to another list—can generate a chain of toasts that the user must mentally reconcile. Even if stacking toasts prevents them from being lost, stacking doesn’t fix the core issue: the confirmation still arrives in the wrong location and at the wrong time relative to the user’s focus.

The alternative proposed is straightforward: use inline feedback where the user is already looking, and treat completion as the signal. Instead of a toast, the “Save” interaction should open the menu right next to the button, show a small loading spinner next to the control, and reveal the updated state directly beneath it. After a checkbox toggle, a loading indicator should appear in place, and when it disappears, the user can infer the action completed—no separate toast needed.

Other examples reinforce the same principle. Gmail’s archiving flow removes the email from the list, which already implies success without extra notifications. Superhuman’s email workflow uses a delayed send window, but its toast-based confirmation still limits what users can do next: if they want to inspect the email before it sends, they can’t click the toast to open it—only “instant send” or “undo” are available. Another critique targets redundant confirmations: if a button already includes built-in confirmation, adding a toast is unnecessary.

The transcript also acknowledges a practical reality: toasts are easy to implement and can look good in demos. A library like Sonner makes it especially convenient by allowing promise-based toast states (loading, success, error). But convenience and aesthetics don’t outweigh usability. The speaker argues that relying on toasts “for everything” becomes especially harmful once they start stacking, and that small, localized UX improvements—like reducing confirmations and making bulk actions possible—can materially improve day-to-day satisfaction, even if they seem minor on paper.