Skip to main content
v1.0.0 | View in Storybook

When to use

  • Promotion: To promote new features or product offerings.
  • Contextual states: To indicate entire application states such as network connectivity issues or trial expiration.
  • Persistent feedback: To display messages that should remain visible at the top of a screen until the user dismisses them or resolves the underlying issue.

When to use something else

  • Task-specific feedback: Do not use a Banner to provide feedback after a user completed or failed a specific task. Depending on the context, consider inline validation, an Alert, Sonner, or Dialog.
  • Navigation: Banners should not be used for internal application navigation. Use the top bar pattern and primitives such as Tabs for in-page structure.
  • Permanent content: Banners are temporary and should not be used for core application functionality that belongs in standard headers or sections.
  • Critical, blocking alerts: Alerts that must be addressed immediately should be displayed with an Alert dialog.

Dos and don’ts

  • Do place the Banner at the top of the UI, above the Topbar.
  • Do respect the max height of the Banner, and keep text to a single line.
  • Don’t stack multiple Banners on top of each other.

Behavior

  • Banners may be dismissible or persistent per product rules (including across sessions for announcements).
  • Banners do not trap focus; critical confirmations belong in Alert dialog.

Often used with

Primary or dismiss Button; optional text link.

Accessibility

  • Landmark structure: Wrap static page-level banners in standard landmark elements like <aside> or <div role="region" aria-label="System Announcement">.
  • Dynamic announcements: For client-side rendered banners, apply role="status" so live updates are announced without interrupting active user keyboard flow.

Visual examples

The examples below are interactive and follow the doc site’s theming: light mode when the docs site is in light mode, and dark mode when you switch the docs site to dark mode.

Variants

Compare Banner alert variants to choose the semantic style—info, warning, error, or neutral—that matches the urgency and type of application-wide message.

Multiple actions

Use multiple actions in a Banner alert when users need both a primary response and a secondary option—for example, “Upgrade now” and “Learn more” for a feature promotion.

Disabled action

Show a disabled action in a Banner alert when an option is temporarily unavailable, and pair it with clear copy explaining why or what the user must do first.

Controlled visibility

Use controlled visibility for Banner alerts when show and hide state must follow application logic—for example, persisting dismissal across sessions or reopening after a connection is restored.

Read only warning

Use the read-only warning Banner alert to inform users they have view-only access and offer a clear path to request edit rights or switch modes.

Info notification

Use an info Banner alert for non-urgent, application-wide announcements such as scheduled maintenance, new features, or general product updates.

Error notification

Use an error Banner alert for critical application states that affect the entire product—for example, lost connectivity or a system-wide failure requiring immediate attention.

Warning notification

Use a warning Banner alert when the application is in a degraded or transitional state that users should know about but can still work around—for example, offline mode or pending sync.
Last modified on September 16, 2026