A small message that appears briefly at the edge of the screen to confirm that something happened, then disappears on its own — no click required to dismiss it.
Toasts exist to close the feedback loop after an action that doesn't change the visible page. Clicking Save in a document editor, sending a message, or deleting a file — the user did something, and the page looks the same. A toast says "it worked" (or "it didn't") without interrupting what comes next.
The defining feature is transience. A toast appears for a few seconds (3–5 is the standard range) and then removes itself. This is what distinguishes it from a banner or an alert dialog — those require an explicit acknowledgment. Toasts are appropriate only for information that is genuinely optional to read. If missing the message would cause a user to make a mistake or lose work, a toast is the wrong choice.
Placement is almost always a corner, most often bottom-left or bottom-right. This keeps toasts out of the main content area and away from primary actions. Top-center is used by some platforms (notably iOS) but risks covering navigation.
Toasts can carry a single action — most commonly Undo. The action window is the toast's own lifespan, which is the user's only warning: once the toast goes away, the action is gone too. For this reason, keep action labels short and the intent obvious.
Avoid stacking more than two or three toasts at once. If your feature triggers toasts in rapid succession, the list scrolling offscreen tells you the pattern isn't right for that flow — consider an in-page notification feed instead.
For accessibility, a toast container needs role="status" (or role="log" if multiple can stack) and aria-live="polite" so screen readers announce the message without interrupting what the user is doing.