Do you know when and where to use toast notifications?

A toast notification is small, but its impact is not.

Poor placement creates confusion. Poor pattern choice creates even more. Some messages belong in a toast, but others need an inline error, banner, dialog, or notification center.

If users hesitate for even a second wondering: "Was that my system or the app?"... you have introduced friction.

For many modern web applications, bottom center is a strong default because it is visible, balanced, and avoids common desktop OS notification zones.

Should your message be a toast?

Before deciding where the toast should appear, first decide whether a toast is the right pattern.

Use a toast when the message is helpful but not critical. If the user needs the information to continue, use a persistent pattern such as an inline message, banner, or dialog.

Toast vs no-toast examples

❌ Figure: Bad example - This should be shown inline, next to the fields that need attention

✅ Figure: Good example - A toast is appropriate for lightweight feedback that confirms a completed action

Where should toast notifications appear?

Comparing toast notification positions

Toast position examples from common products

There is no universal convention. Different products optimize for different layouts, platforms, and interaction patterns.

The important takeaway is consistency, not imitation. At SSW, the default is bottom center because it gives a stronger cross-platform baseline and avoids the primary OS notification zones on both platforms (macOS top right, Windows bottom right).

Recommendations

✅ Choose bottom center

• Aligns with Material Design and modern cross-platform UX
• Works consistently on desktop and mobile
• Avoids macOS top-right and Windows bottom-right OS notification zones
• Common in products like Figma and X
• SSW standard for new web applications

👍 Bottom right is a strong alternative

• Common in enterprise SaaS apps
• Familiar to many desktop-first users
• Strong fit when your layout keeps key actions away from the lower-right corner
• Validate carefully on Windows, where OS notifications can appear in the same corner

⚠️ Use caution with top right

macOS Notification Center sits in the top-right corner of every Mac screen. Placing in-app toasts in the same zone can create two compounding problems:

• OS-level notifications can physically overlap and hide in-app toasts
• Users cannot reliably distinguish between a system notification and an app notification, breaking trust and clarity

Only use top-right placement when platform constraints and user testing clearly justify it.

Toast text content structure

Position is only half the UX. The wording inside a toast determines whether users understand what happened and what to do next.

Use these text structure components:

• Message / Body (Mandatory): A concise, usually single-sentence message that explains the outcome, such as success, failure, or a status update
• Headline / Title (Optional): A brief summary like "Success" or "Error" shown before the message when extra emphasis is helpful
• Action Label (Optional): Short button text like "Undo" or "Retry" for a directly related next step

Keep all toast text in sentence case, and keep titles concise and to the point.

Toast message examples

Toast styling

Toast notifications should be easy to scan, visually calm, and clearly tied to the message type. Avoid making every toast look urgent.

Use icons to help users understand the message faster, but do not rely on icons alone. Pair them with clear text. See the rule Do you use icons to reinforce meaning?.

Toast styling should match the message severity. A toast should be noticeable enough to confirm what happened, but not so loud that it distracts from the user’s task.

For more information, see Carbon Design System - Notification style.

Accessibility requirements

Toast placement is not just visual. It is semantic. Implementation must also satisfy WCAG 2.2 requirements.

Follow WCAG guidance:

• Use role="status" for success and informational toasts
  • Polite ARIA live region
  • Screen readers announce after the current task
• Use role="alert" for errors
  • Assertive
  • Screen readers interrupt immediately
• For auto-dismissing toasts, use a practical minimum such as 4–6 seconds for short, non-critical messages. If the toast contains important information or an action, provide a way to pause, extend, dismiss manually, or access the information elsewhere. (WCAG 2.2 - Success Criterion 2.2.1 Timing Adjustable)
• Never auto-dismiss error toasts
• Do not cover primary CTAs or form fields

If you are building a modern SaaS or enterprise web application, default to bottom center.

Small details build trust. Predictability reduces friction.