By Mehdi HassanMost cookie banners are designed by three people who never talk: a lawyer who wants every disclosure, a marketer who wants every acceptance and a developer who pastes in a script. The result annoys visitors and often isn't compliant either. This guide treats the banner as one piece of design, legal and tracking work. It connects to our GA4 setup guide for marketing websites, where the consent signals end up.
What makes good cookie banner design?
Good cookie banner design gives a real, equal choice, uses plain language, doesn't block the page and works for every visitor, including keyboard and screen-reader users. It also loads fast and matches the site's visual style, so it doesn't look like a scam pop-up.
Element | Do | Don't |
|---|---|---|
Buttons | Accept all and Reject all, same style and size | A bright Accept and a grey text link to reject |
Defaults | Non-essential categories off | Pre-ticked boxes or implied consent on scroll |
Copy | One or two sentences in plain words | A paragraph of legal text |
Placement | Bottom bar or corner card | A full-screen wall over the content |
Settings | One click to granular categories | Settings buried three screens deep |
Later changes | A persistent privacy settings link | No way to change your mind |
Style | Your fonts, colors and spacing | Default vendor styling that looks foreign |
What does a GDPR cookie banner legally need?
A GDPR cookie banner, under the EU's ePrivacy rules and GDPR, needs consent that is freely given, specific, informed and unambiguous, collected before non-essential cookies are set. In practice: no pre-ticked boxes, rejecting must be as easy as accepting, and withdrawing consent must be possible at any time.
Strictly necessary cookies, such as those for security or a shopping cart, don't need consent. Analytics, advertising and most third-party embeds do. You also need to record consent choices, and your cookie policy should list what each category contains. The European Court of Justice ruled against pre-ticked consent boxes in the Planet49 case, and European regulators have since targeted banners that make rejection harder than acceptance.
How should cookie banners work for US visitors?
For US visitors, most state privacy laws follow an opt-out model rather than opt-in, so tracking can start by default while visitors get a clear way to opt out of the sale or sharing of their data. California's rules also expect sites to honor the Global Privacy Control signal from the browser.
That means one banner design rarely fits every region. Most consent platforms let you show an opt-in banner in the EU, UK and Switzerland and a lighter notice with a Do Not Sell or Share link elsewhere. Set this up by region in the consent platform, and keep the same visual style everywhere. If you're also localizing the site, check that the banner follows the language switcher choice.
How do you make a cookie consent banner accessible?
Make a cookie consent banner accessible by using real buttons, a logical focus order, sufficient contrast and a clear label for assistive technology. The banner is often the first thing on the page, so if it fails, the visitor can't use the site at all.
- Real buttons: use button elements with visible text, not styled divs or icons alone.
- Focus: move focus to the banner when it appears, and return it sensibly after a choice. Don't trap focus in a non-modal banner.
- Contrast: both buttons and the body text must meet contrast requirements against the banner background.
- Labels: give the banner a region or dialog role with an accessible name, such as Cookie preferences.
- Zoom and mobile: the banner must work at high zoom and never cover the close or action buttons on small screens.
Our guide to accessible design basics covers contrast and focus states in more depth.
How does the banner connect to your tracking?
The banner connects to tracking through your consent platform, which tells Google tags through Consent Mode and blocks other tags until the right category is granted. If that link is broken, the banner is decoration, and you're either collecting without consent or losing data you're allowed to collect.
Set privacy-first defaults
In opt-in regions, deny all non-essential categories by default, before any tag fires.
Map categories to tags
Analytics tags need the analytics category; ads pixels need advertising. Write the mapping into your tracking plan.
Send updates instantly
When the visitor chooses, the consent platform must update tags on the same page view, without a reload.
Test every path
Check accept, reject, partial consent and a later change in Tag Assistant, as described in our Consent Mode v2 guide.
For example, suppose a startup redesigns its banner
For example, suppose a SaaS startup has a vendor-default banner: a large Accept button, a small Settings link and pre-ticked analytics. The redesign puts Accept all and Reject all side by side with equal styling, adds a Customize button that opens three plainly named categories, and unticks everything by default in the EU.
The developer moves the consent tag to fire first in Tag Manager and maps each category to its tags. Acceptance may drop compared with the old design, which is the honest cost of a fair choice. To keep useful traffic numbers regardless, the team adds a cookieless tool, as compared in our guide to privacy-friendly analytics.
What are the most common cookie banner design mistakes?
The most common cookie banner design mistakes are hiding the reject option, loading tags before consent, covering the content on mobile and writing copy nobody understands. Each one either breaks the rules, breaks the experience or both.
- Accept is a button, reject is a link: regulators treat unequal choices as a dark pattern.
- Tags fire on page load anyway: the banner shows, but Google and ads tags run before the answer.
- Full-screen walls on mobile: visitors leave before reading anything.
- Banner reappears on every page: the choice isn't stored, often because of a domain or subdomain setting.
- No way back: there's no footer link to reopen preferences.
- Vendor styling: a banner that looks foreign to the site reads as untrustworthy.
Treat the banner like any other component: design it in your system, test it on real devices and include it in your release checks. For ongoing upkeep, our comparison of a website care plan vs a design retainer explains who should own it after launch.
