ui patterns
Modal vs toast
Modal or toast - which should confirm an action?
Two ways to communicate that something has happened. A modal halts activity and requires a response before proceeding; a toast appears briefly, delivers its message, then disappears. One interrupts, one glides away - and choosing the wrong one creates a usability issue.
Also known as: toast vs modal, dialog vs toast
Prefer to watch?
Watch the recap 0:40
The demo
Two actions, two ways to confirm each. Try a routine save and a permanent delete with both a modal and a toast - and feel which pairing is right and which grates.
Try each action with each style and notice which feels right.
What this demo shows (text version)
Two actions - "save changes" (routine, reversible) and "delete account" (destructive, permanent) - each confirmed using either a modal or a toast. A modal blocks the page until you dismiss it; a toast slides in briefly and disappears.
Confirming a routine save with a modal feels like a pointless interruption, while a toast suits it perfectly. But confirming a permanent delete with a toast is dangerous - it should be a modal that makes you stop and confirm before anything is destroyed. The lesson is to match the interruption to the stakes: modals for decisions that must not be missed, toasts for routine feedback that shouldn't get in the way.
A modal stops everything and demands a response; a toast slides in, says its piece, then leaves - one interrupts, one whispers. Use the right one for the right stakes: a modal for consequential, irreversible actions; a toast for routine confirmations that should clear the way.
Confirming a routine save with a modal made you stop and click "OK" for no reason - an interruption tax. The toast did the same job and got out of the way. Flip it for a destructive action, though, and the toast that vanishes is exactly wrong. Match the weight of the interruption to the weight of the moment.
Reach for a modal only when the user genuinely must stop and decide: a destructive confirmation ("delete forever?"), a blocking error, a choice the flow can't continue without. Its whole power is that it can't be ignored - which is also its whole cost, so spend it rarely.
Reach for a toast for routine, reversible, non-critical feedback: "saved", "copied", "added to basket" - ideally with an undo. Its strength is that it doesn't block; its weakness is that it can be missed, so never put anything the user must see or act on in something that disappears. See [modal dialog](/entries/modal-dialog/) and [toast notification](/entries/toast-notification/) for each on its own.