Back to compare picker

Cookie banner vs Banner vs Notification banner vs Site alert

Choose cookie banner when the interface must tell users about cookies or similar storage, separate essential from non-essential purposes, collect accept or reject choices, save the preference, and prevent optional tracking before consent.

Decision dimensions

Dimension Cookie bannerBannerNotification bannerSite alert
UI or UX UI + UX - Cookie and tracking consent controlUI + UX - Top-of-interface broad-scope messageUI + UX - Page-flow service notification before the H1UI + UX - Urgent full-width sitewide alert near the top of every page
UI guidance Render a clearly labelled cookie banner at the top of the document before ordinary page content, with service-specific copy, essential-cookie information, equal accept and reject actions for non-essential purposes, and a link to detailed cookie settings.Render the banner at the top of the interface or content area it governs, below required global chrome and before the page content that should be interpreted with that message.Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content.Render the site alert as a full-width message near the top of the site, before ordinary navigation or page content users might otherwise start from.
UX guidance Use a cookie banner to collect or confirm choices for non-essential cookies, local storage, pixels, service-worker storage, analytics, advertising, personalization, or similar device storage technologies.Use banners when users need broad context before continuing across several pages or sections, such as maintenance, service delay, account setup, rollout, policy, or official-site identity information.Use notification banners sparingly for information users need before interpreting the page but that is not the main task content on that page.Use a site alert when urgent public or servicewide information must be obvious and findable from any page, including deep links, refreshes, and routes outside the home page.
Good UI A service banner says it uses essential cookies and asks to use analytics cookies, with Accept analytics cookies, Reject analytics cookies, and View cookies controls at the same level.A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe.A case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status.A public benefits site shows Emergency office closures at the very top of every page, with affected offices, updated time, and a link to alternate service channels.
Bad UI A banner has a large Accept all button and a small Manage settings link but no reject action on the first layer.Three unrelated banners stack above the page heading and push the account task below the fold.A validation error appears in a notification banner at the top of the page with no links to the invalid fields.The emergency message appears only on the home page, so users who land on Apply or Help do not see it.
Good UX A first-time visitor rejects analytics cookies and the site loads without optional analytics, while essential security cookies remain explained.A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey.A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.
Bad UX Reject only closes the banner while ad pixels and analytics continue firing.A field validation error appears in a banner, forcing users to hunt for the failing input.The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record.Users dismiss a critical emergency alert once and never see a later update because dismissal is not versioned.
Best fit The service sets non-essential cookies or similar device storage technologies.The message applies across several pages, routes, sections, records, or sessions.A message should be encountered before the page H1 but is not the page's main task content.Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.
Avoid when The service uses only strictly necessary cookies and can explain them on a cookies page.The message affects only one field, object, row, panel, or local task section.The message is a submitted-form validation error or field correction.The message applies only to one product workspace, account, section, page flow, field, row, or task.
Required state First visit with no saved preference.No-banner state when no broad-scope message applies.No-banner state when no service-context notice or previous-page outcome applies.No-site-alert state when no urgent sitewide condition applies.
Accessibility burden Label the cookie banner region with the service name so users know which service is asking for the choice.Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice.Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation.
Common misuse Accept-only banners.Using a banner for one field error, one row warning, or one card status.Using a notification banner for field validation errors instead of an error summary and field-level messages.Showing a sitewide emergency only on the home page.

Cookie banner

UI or UX
UI + UX - Cookie and tracking consent control
UI guidance
Render a clearly labelled cookie banner at the top of the document before ordinary page content, with service-specific copy, essential-cookie information, equal accept and reject actions for non-essential purposes, and a link to detailed cookie settings.
UX guidance
Use a cookie banner to collect or confirm choices for non-essential cookies, local storage, pixels, service-worker storage, analytics, advertising, personalization, or similar device storage technologies.
Good UI
A service banner says it uses essential cookies and asks to use analytics cookies, with Accept analytics cookies, Reject analytics cookies, and View cookies controls at the same level.
Bad UI
A banner has a large Accept all button and a small Manage settings link but no reject action on the first layer.
Good UX
A first-time visitor rejects analytics cookies and the site loads without optional analytics, while essential security cookies remain explained.
Bad UX
Reject only closes the banner while ad pixels and analytics continue firing.
Best fit
The service sets non-essential cookies or similar device storage technologies.
Avoid when
The service uses only strictly necessary cookies and can explain them on a cookies page.
Required state
First visit with no saved preference.
Accessibility burden
Label the cookie banner region with the service name so users know which service is asking for the choice.
Common misuse
Accept-only banners.

Banner

UI or UX
UI + UX - Top-of-interface broad-scope message
UI guidance
Render the banner at the top of the interface or content area it governs, below required global chrome and before the page content that should be interpreted with that message.
UX guidance
Use banners when users need broad context before continuing across several pages or sections, such as maintenance, service delay, account setup, rollout, policy, or official-site identity information.
Good UI
A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe.
Bad UI
Three unrelated banners stack above the page heading and push the account task below the fold.
Good UX
A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.
Bad UX
A field validation error appears in a banner, forcing users to hunt for the failing input.
Best fit
The message applies across several pages, routes, sections, records, or sessions.
Avoid when
The message affects only one field, object, row, panel, or local task section.
Required state
No-banner state when no broad-scope message applies.
Accessibility burden
Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.
Common misuse
Using a banner for one field error, one row warning, or one card status.

Notification banner

UI or UX
UI + UX - Page-flow service notification before the H1
UI guidance
Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content.
UX guidance
Use notification banners sparingly for information users need before interpreting the page but that is not the main task content on that page.
Good UI
A case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status.
Bad UI
A validation error appears in a notification banner at the top of the page with no links to the invalid fields.
Good UX
A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey.
Bad UX
The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record.
Best fit
A message should be encountered before the page H1 but is not the page's main task content.
Avoid when
The message is a submitted-form validation error or field correction.
Required state
No-banner state when no service-context notice or previous-page outcome applies.
Accessibility burden
Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice.
Common misuse
Using a notification banner for field validation errors instead of an error summary and field-level messages.

Site alert

UI or UX
UI + UX - Urgent full-width sitewide alert near the top of every page
UI guidance
Render the site alert as a full-width message near the top of the site, before ordinary navigation or page content users might otherwise start from.
UX guidance
Use a site alert when urgent public or servicewide information must be obvious and findable from any page, including deep links, refreshes, and routes outside the home page.
Good UI
A public benefits site shows Emergency office closures at the very top of every page, with affected offices, updated time, and a link to alternate service channels.
Bad UI
The emergency message appears only on the home page, so users who land on Apply or Help do not see it.
Good UX
A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.
Bad UX
Users dismiss a critical emergency alert once and never see a later update because dismissal is not versioned.
Best fit
Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.
Avoid when
The message applies only to one product workspace, account, section, page flow, field, row, or task.
Required state
No-site-alert state when no urgent sitewide condition applies.
Accessibility burden
Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation.
Common misuse
Showing a sitewide emergency only on the home page.
Decision rules
  • Choose cookie banner when the interface must tell users about cookies or similar storage, separate essential from non-essential purposes, collect accept or reject choices, save the preference, and prevent optional tracking before consent.
  • Choose banner when a broad product, workspace, account, or service message applies across multiple pages but does not collect consent or control storage on the user's device.
  • Choose notification banner when a page-flow notice belongs immediately before the H1, such as a deadline, service problem, or previous-page outcome, and is not a consent mechanism.
  • Choose site alert when urgent public or sitewide information must appear near the top of every affected page, regardless of cookie or tracking preferences.
  • A cookie banner must provide a real reject path wherever optional cookies are offered, and preference management must remain reachable after the banner is hidden.
  • A cookie banner must not set non-essential cookies, pixels, analytics, local storage, service-worker storage, or similar tracking before the user accepts the relevant purpose.
  • Do not style accept as the only visible action or make reject harder to find; misleading contrast, preselected options, and paragraph-only reject links undermine valid choice.
  • Do not turn a cookie banner into a blocking modal, sticky overlay, marketing banner, legal acceptance gate, or privacy-policy-only notice.
Inspect live examples
Failure modes
  • A cookie banner has Accept all and Manage settings but no visible reject option, so users cannot refuse with comparable effort.
  • Analytics and ad pixels fire before users make a choice, making the visible banner disconnected from actual tracking behavior.
  • A broad outage banner is implemented as a cookie banner, forcing users to make a privacy choice before reading a service-status message.
  • A before-H1 upload confirmation is mixed into cookie preferences, so users mistake a service outcome for a tracking decision.
  • An emergency site alert is hidden after a user rejects analytics cookies, even though public-safety content should remain visible.
  • A cookie banner saves one vague accepted flag instead of storing purpose-level choices, timestamp, version, and withdrawal route.