Slack-style notification toast animation in CSS

The notification toast is one of the most-implemented UI elements and one of the most-misjudged. Most toasts are either too aggressive (sliding in from a corner, blocking content, demanding action) or too quiet (appearing without motion, easy to miss). The Slack toast — discreet slide-in, sits for a few seconds, fades out, hover-pauses — has been the gold standard since 2015 for good reasons.

Here is how to build it from scratch in CSS, including the details that make the difference between "a notification" and "a Slack-style notification."

The four motion beats

A good toast has four:

1. Slide-in (200–300ms, ease-out). From off-screen edge, into final position. Decisive.
2. Settle (50ms, no overshoot for toasts). Quieter than a button press.
3. Hover-pause (state-driven). When the cursor enters, freeze the dismiss timer.
4. Slide-out (200ms, ease-in). Reverse direction, slightly faster than the entry.

The total runtime — from spawn to dismissed — is 4 to 6 seconds for an info-level toast, 8+ for an action-required toast.

The slide direction

Toasts spawn from one of four corners. The right-bottom and right-top are the conventional defaults; both work, the bottom is slightly better because the eye is more often there.

Direction of motion: always from off-screen toward the center of the viewport. Bottom-right toast slides up-and-left? No — it slides in from the right edge. Bottom-center toast slides up. Top-right toast slides from the right. The motion vector points toward where it will rest, with the off-screen origin matching the closest edge.

The progress bar (optional but high-leverage)

A 2px bar at the bottom of the toast that drains over the auto-dismiss duration. Two reasons it's worth adding:

1. Feedback. The user knows the toast will dismiss itself. Without the bar, they don't know if they need to act.
2. Pause indicator. When the mouse enters, the bar's animation pauses. The user sees that hovering keeps the toast alive.

Implement with transform: scaleX() and transform-origin: left so the bar drains rightward.

.toast-bar {
  transform-origin: left;
  animation: drain 4s linear forwards;
}
.toast:hover .toast-bar {
  animation-play-state: paused;
}
@keyframes drain { to { transform: scaleX(0); } }

Stacking

When two toasts coexist, the second pushes the first up (or down, depending on origin). The position transition is a 200ms ease-out on transform: translateY().

The rule for stack height: max 3 toasts visible. Beyond that, older toasts dismiss themselves immediately to make room. A stack of 8 toasts is a UX failure regardless of how smoothly they animate.

Toast severity levels

Four levels, each with a distinct visual treatment:

The "sticky on error" rule is the one most apps get wrong. An error toast that disappears in 4 seconds is information the user often misses.

Accessibility, briefly

• role="status" for info/success.
• role="alert" for warning/error — screen readers interrupt to read these.
• aria-live="polite" on the toast container.
• Honor prefers-reduced-motion — replace slide with a 100ms fade.

These are five lines of code that make the toast usable for ~15% more of your users.

Rendering to MP4 (for onboarding videos)

The toast pattern lifts directly into the render pipeline. Two use cases:

• Onboarding walkthroughs — render a toast sequence showing the user what notifications they'll see.
• Marketing site demos — a fake toast on a hero shot, demoing the product without requiring a real login.

Set the loop to 4 seconds (in + settle + out + 500ms gap) and the toast reads as ambient motion on the hero.

Open the playground, drop the toast in, render the onboarding clip.