Back to compare picker

Official-site banner vs Banner vs Site alert vs Notification banner vs Security warning vs Service navigation

Choose official-site banner when users need to verify that a page belongs to an official government organization and understand the trusted domain and HTTPS indicators before sharing sensitive information.

Decision dimensions

Dimension Official-site bannerBannerSite alertNotification bannerSecurity warningService navigation
UI or UX UI + UX - Top-of-page official identity and secure-connection disclosure for eligible government or public-authority websitesUI + UX - Top-of-interface broad-scope messageUI + UX - Urgent full-width sitewide alert near the top of every pageUI + UX - Page-flow service notification before the H1UI + UX - Security-risk warning and safe interruption before unsafe navigation, download, submission, preview, or sensitive actionUI + UX - Service-scoped identity and navigation strip
UI guidance Place the official-site banner at the very top of every eligible page, before the header, service navigation, alerts, and page content.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 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.Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content.Render a security warning as a high-clarity interruption that names the detected risk, identifies the destination or object, explains the concrete threat, presents the safest action as the primary path, and separates any override behind deliberate risk detail.Render the service name, service-home link, a compact set of service-level links, current or active service state, and any service-level tools in a navigation strip below the general site or platform header.
UX guidance Use the banner to help users verify official ownership and secure connection status before they share personal, financial, health, legal, or account information.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 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.Use notification banners sparingly for information users need before interpreting the page but that is not the main task content on that page.Use security warning when a product, browser, operating system, or service has evidence that proceeding could expose credentials, install harmful software, leak sensitive data, bypass trust, or weaken account protection.Use service navigation to reassure users that they are inside the right service and to let repeated or multi-task users move among the most important service areas.
Good UI A benefits service shows an official government banner above the header with a flag, official-site text, a How you know disclosure, and expanded .gov plus HTTPS explanations.A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe.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.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 browser interstitial says Deceptive site ahead, shows the suspicious domain, explains that attackers may steal passwords, and makes Back to safety the primary action while placing Visit unsafe site behind Details.A benefits service shows the GOV.UK header above a light service strip with 'Apply for support', Overview, Applications, Messages, and a Welsh language link.
Bad UI A private vendor checkout copies government official-site copy while using a commercial domain.Three unrelated banners stack above the page heading and push the account task below the fold.The emergency message appears only on the home page, so users who land on Apply or Help do not see it.A validation error appears in a notification banner at the top of the page with no links to the invalid fields.A red page says Security issue with Continue as the only visible action.The service strip mixes GOV.UK topics, start-page links, sign out, Help, local page anchors, and admin tools as equal destinations.
Good UX A user expands the banner before entering a tax ID, reads that .gov belongs to an official government organization, checks the HTTPS guidance, and continues with more confidence.A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey.A user clicks a payroll link that visually resembles the company domain, sees the suspicious-domain warning, returns to the trusted site, and reports the link to security.A caseworker switches from Applications to Messages and returns to Applications with draft progress and filters preserved.
Bad UX A staging site uses official banner copy during a user test and participants believe it is a live government service.A field validation error appears in a banner, forcing users to hunt for the failing input.Users dismiss a critical emergency alert once and never see a later update because dismissal is not versioned.The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record.A user sees a vague warning, assumes it is routine maintenance, proceeds, and enters credentials into a phishing page.A linear eligibility check exposes service navigation that invites users to leave before completing the required questions.
Best fit The service is eligible to identify itself as an official government or public-authority website.The message applies across several pages, routes, sections, records, or sessions.Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.A message should be encountered before the page H1 but is not the page's main task content.A threat signal indicates phishing, malware, deceptive site, unsafe download, invalid certificate, insecure connection, mixed-content submission, suspicious redirect, file preview risk, or account-security danger.A named service is used repeatedly by some users.
Avoid when The site is not an official government or public-authority service.The message affects only one field, object, row, panel, or local task section.The message applies only to one product workspace, account, section, page flow, field, row, or task.The message is a submitted-form validation error or field correction.The message is only a general severe consequence before a product action; use warning text.The journey is a simple end-to-end transaction with a clear sequence.
Required state Collapsed official identity state.No-banner state when no broad-scope message applies.No-site-alert state when no urgent sitewide condition applies.No-banner state when no service-context notice or previous-page outcome applies.Safe path state with primary Back to safety, Cancel, Remove, Use trusted route, or Contact admin action.Default state with general header, visible service name, service-home link, and service navigation links.
Accessibility burden Use the approved semantic structure and labels for the banner landmark or region.Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation.Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice.Use a heading and text that name the risk before the destination or details, so screen reader users hear the warning context first.Use a correctly labelled service information region or navigation landmark that reflects the service name and link list.
Common misuse Copying an official government banner onto a private, partner, staging, or prototype site.Using a banner for one field error, one row warning, or one card status.Showing a sitewide emergency only on the home page.Using a notification banner for field validation errors instead of an error summary and field-level messages.Using vague warning copy that does not say phishing, malware, certificate, insecure connection, dangerous download, or suspicious redirect.Using service navigation as a site map for every page in the service.

Official-site banner

UI or UX
UI + UX - Top-of-page official identity and secure-connection disclosure for eligible government or public-authority websites
UI guidance
Place the official-site banner at the very top of every eligible page, before the header, service navigation, alerts, and page content.
UX guidance
Use the banner to help users verify official ownership and secure connection status before they share personal, financial, health, legal, or account information.
Good UI
A benefits service shows an official government banner above the header with a flag, official-site text, a How you know disclosure, and expanded .gov plus HTTPS explanations.
Bad UI
A private vendor checkout copies government official-site copy while using a commercial domain.
Good UX
A user expands the banner before entering a tax ID, reads that .gov belongs to an official government organization, checks the HTTPS guidance, and continues with more confidence.
Bad UX
A staging site uses official banner copy during a user test and participants believe it is a live government service.
Best fit
The service is eligible to identify itself as an official government or public-authority website.
Avoid when
The site is not an official government or public-authority service.
Required state
Collapsed official identity state.
Accessibility burden
Use the approved semantic structure and labels for the banner landmark or region.
Common misuse
Copying an official government banner onto a private, partner, staging, or prototype site.

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.

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.

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.

Security warning

UI or UX
UI + UX - Security-risk warning and safe interruption before unsafe navigation, download, submission, preview, or sensitive action
UI guidance
Render a security warning as a high-clarity interruption that names the detected risk, identifies the destination or object, explains the concrete threat, presents the safest action as the primary path, and separates any override behind deliberate risk detail.
UX guidance
Use security warning when a product, browser, operating system, or service has evidence that proceeding could expose credentials, install harmful software, leak sensitive data, bypass trust, or weaken account protection.
Good UI
A browser interstitial says Deceptive site ahead, shows the suspicious domain, explains that attackers may steal passwords, and makes Back to safety the primary action while placing Visit unsafe site behind Details.
Bad UI
A red page says Security issue with Continue as the only visible action.
Good UX
A user clicks a payroll link that visually resembles the company domain, sees the suspicious-domain warning, returns to the trusted site, and reports the link to security.
Bad UX
A user sees a vague warning, assumes it is routine maintenance, proceeds, and enters credentials into a phishing page.
Best fit
A threat signal indicates phishing, malware, deceptive site, unsafe download, invalid certificate, insecure connection, mixed-content submission, suspicious redirect, file preview risk, or account-security danger.
Avoid when
The message is only a general severe consequence before a product action; use warning text.
Required state
Safe path state with primary Back to safety, Cancel, Remove, Use trusted route, or Contact admin action.
Accessibility burden
Use a heading and text that name the risk before the destination or details, so screen reader users hear the warning context first.
Common misuse
Using vague warning copy that does not say phishing, malware, certificate, insecure connection, dangerous download, or suspicious redirect.

Service navigation

UI or UX
UI + UX - Service-scoped identity and navigation strip
UI guidance
Render the service name, service-home link, a compact set of service-level links, current or active service state, and any service-level tools in a navigation strip below the general site or platform header.
UX guidance
Use service navigation to reassure users that they are inside the right service and to let repeated or multi-task users move among the most important service areas.
Good UI
A benefits service shows the GOV.UK header above a light service strip with 'Apply for support', Overview, Applications, Messages, and a Welsh language link.
Bad UI
The service strip mixes GOV.UK topics, start-page links, sign out, Help, local page anchors, and admin tools as equal destinations.
Good UX
A caseworker switches from Applications to Messages and returns to Applications with draft progress and filters preserved.
Bad UX
A linear eligibility check exposes service navigation that invites users to leave before completing the required questions.
Best fit
A named service is used repeatedly by some users.
Avoid when
The journey is a simple end-to-end transaction with a clear sequence.
Required state
Default state with general header, visible service name, service-home link, and service navigation links.
Accessibility burden
Use a correctly labelled service information region or navigation landmark that reflects the service name and link list.
Common misuse
Using service navigation as a site map for every page in the service.
Decision rules
  • Choose official-site banner when users need to verify that a page belongs to an official government organization and understand the trusted domain and HTTPS indicators before sharing sensitive information.
  • Choose banner when the message is a broad product, workspace, account, maintenance, rollout, or policy notice that is not primarily proving official ownership or connection security.
  • Choose site alert when urgent sitewide conditions such as emergency closure, outage, public-service disruption, or time-critical incident must appear across affected pages.
  • Choose notification banner when a service notice belongs before the page heading, such as previous-page success, approaching personal deadline, or service delay, and is not an official identity claim.
  • Choose security warning when the system detects phishing, malware, certificate, unsafe-download, mixed-content, suspicious-redirect, or file-preview risk; official-site banner explains normal trusted-site indicators, not an active threat.
  • Choose service navigation when users need the service name, service-home link, current section, and service-level links; official-site banner sits above the header and should not carry navigation destinations.
  • An official-site banner should appear consistently at the very top of every eligible page, use the jurisdiction's approved official identity text, disclose domain rules such as .gov or .mil, explain HTTPS or lock indicators, and avoid acting like a dismissible marketing banner.
  • Do not use official-site banner on staging, prototype, partner, private-company, non-government, or non-HTTPS surfaces where it would imply government ownership or safety that the page cannot prove.
  • Do not replace official-site banner with a logo, agency header, service navigation, footer seal, site alert, or warning text; those can support identity but do not teach users how to verify official and secure status.
  • When a page is official but not on the expected trusted domain or not using HTTPS, fix the domain and transport problem instead of changing banner copy to make the page appear official.
Inspect live examples
Failure modes
  • A private contractor site copies a government official-site banner even though the page is not on an eligible government domain.
  • A real agency site hides official identity in the footer, so users cannot verify the site before entering personal information.
  • The official-site banner is dismissible and disappears before users can expand the .gov and HTTPS explanation.
  • The banner is used as a maintenance message, pushing actual official-domain guidance into ordinary notification text.
  • An HTTP page shows secure-site language even though the connection is not encrypted.
  • A service navigation row includes official-site proof text and domain advice as if it were just another navigation item.