Cookie Banner: What the Law Requires in 2026, and How to Build One That Doesn't Wreck Your Data

A cookie banner is the one piece of interface almost every site has and almost nobody designs. It arrives with the consent platform, gets its colours changed to match the brand, and is never looked at again. Then one of three things happens: a regulator writes, the analytics account quietly loses half its sessions, or Core Web Vitals turn red and nobody connects it to the thing sliding in at the top of every page.

All three are avoidable, and they have the same root cause: the banner is treated as a legal formality rather than as a piece of measurement infrastructure. This guide covers what the law actually requires in 2026, in the EU, the UK and the US, what regulators enforce in practice, whether you need a banner at all, and how to implement one that satisfies the rules without destroying your data or your page performance. The worked example is this site’s own banner, because it is the one I can show you the code for.

None of this is legal advice. It is a practitioner’s reading of the primary sources, with links to every one of them so you can check.

Key takeaways

• A cookie banner exists to collect valid consent before non-essential storage or access happens, and consent means a clear positive action, not scrolling or continuing to browse.
• The EDPB Cookie Banner Taskforce report treats a missing reject option, pre-ticked boxes and reject links buried in text as invalid consent.
• The UK now has five consent exceptions, including a narrow one for statistical analytics, in guidance the ICO finalised on 29 April 2026.
• Google’s Consent Mode v2 has to be wired so defaults run before any tag and updates fire on interaction, or the banner is compliant and your data is gone anyway.
• Cookie notices are one of the most common causes of layout shift on the web, and a footer or modal placement avoids it.

What a cookie banner is, and what it is legally for

A cookie banner is the interface a website uses to tell visitors that it stores or reads information on their device, and to collect their permission before it does so for anything that is not essential. The legal object is the consent, not the banner. The cookie banner is one way of obtaining it, and the law is mostly silent on what it should look like, which is why so many of them look wrong.

The standard the consent has to meet is the one in the GDPR, applied to cookies through the ePrivacy rules and their national transpositions. The ICO’s guide to PECR puts it plainly: consent must be freely given, specific and informed, must involve an unambiguous positive action, must be more than simply continuing to use the website, and non-essential cookies cannot be set before the user has consented. Those four properties define the cookie banner’s job. Everything about design, timing and wording follows from them.

Two clarifications save a lot of confusion. First, the rules cover any storage or access on the device, not only cookies: local storage, pixels, fingerprinting and tag scripts all count. Second, the rules apply whether or not the data is personal. A first-party analytics cookie that never identifies anyone still needs a lawful route, which is either consent or one of the exceptions covered below.

The law in 2026: EU, UK and US

The three jurisdictions most sites have to think about have diverged, and the differences matter for implementation.

The EU: the taskforce set the floor

In the EU, storing or reading information on a device needs consent unless it is strictly necessary for a service the user asked for, and the consent has to meet the GDPR standard. The most useful document on what that means for a banner is the EDPB Cookie Banner Taskforce report, adopted on 17 January 2023 by the national authorities coordinating their handling of hundreds of complaints. It records the common floor the participating authorities settled on:

• A banner with an accept button but no reject option on any layer that carries a consent button is, for a vast majority of authorities, not valid consent and therefore an infringement.
• Pre-ticked boxes on the second layer do not lead to valid consent.
• A reject option offered only as a link embedded in a paragraph of text, without visual support to draw attention to it, does not produce valid consent.
• Button colours and contrasts are assessed case by case, but a reject button whose text is unreadable against its background is manifestly misleading.
• Legitimate interest cannot be the legal basis for placing or reading cookies, whatever the second layer of the banner says.
• Withdrawing consent must be as easy as giving it, and an easily accessible way to withdraw must exist on every page.

That is the floor. National authorities add their own requirements on top, and the report is explicit that it reflects a minimum common denominator rather than a safe harbour.

The EU: what is changing, and what is not yet law

The rules above come from the ePrivacy Directive, which the EU has been trying to replace for years. The current attempt is the Digital Omnibus. According to the European Parliament’s legislative train, updated on 1 August 2026, the Commission’s proposal of 19 November 2025 would move cookie consent rules from the ePrivacy Directive into the GDPR, expand the list of activities exempt from consent, and let users give one-click consent valid for six months or save preferences at browser or system level, while keeping consent as the primary criterion for accessing data on a device.

It is not law, and as of the summer it was not close. The same source records that the Parliament co-rapporteurs’ draft report of 22 June 2026 left the cookie provisions to committee negotiation, that over 1,750 amendments were tabled, and that the Council’s mandate vote scheduled for 26 June was cancelled when agreement could not be found. Build to the current rules. If the Omnibus passes in something like its proposed form, a banner that already collects granular consent and honours browser signals will need adjusting, not replacing.

The UK: five exceptions and a new enforcement regime

The UK’s rules sit in PECR, and they changed with the Data (Use and Access) Act 2025. The ICO’s storage and access technologies guidance was finalised on 29 April 2026 after two consultations, one on the rewritten guidance in December 2024 and one on the Act’s PECR changes in July 2025. It is the document to work from.

The most practical change is the exceptions. The ICO’s chapter on the exceptions lists five circumstances in which no consent is needed: transmission of a communication, strict necessity for a service the user requested, statistical purposes, adapting the appearance or functionality of the service to the user’s preference, and emergency assistance. Two of those are new for most sites. The statistical exception covers aggregate analytics about how your service is used, with a view to improving it, and only that: no tracking of individuals, no advertising measurement, and the provider must act as your processor. The appearance exception covers things like remembering a language choice or honouring dark mode. Both require clear information and a simple, free means of objecting.

The ICO also states that you must not rely solely on browser settings as evidence that a user does not object.

Two lines from the same chapter settle most arguments. There are no advertising purposes that meet the strictly necessary exception. And a cookie that remembers the user’s consent choice for a period such as 90 days can itself be exempt, provided it is used for nothing else.

Enforcement is changing too. The ICO’s enforcement chapter says that, with the Act coming into law on 19 June 2025, the PECR enforcement regime is being aligned with the UK GDPR regime, and that new enforcement guidance will follow. The practical reading is that cookie failures move from a low-ceiling penalty regime to the same one as data protection breaches.

The US: opt-out, not opt-in

There is no federal cookie consent law in the United States. The state laws that exist are opt-out regimes, and California’s is the model. The California Attorney General’s CCPA page sets out that the law applies to for-profit businesses doing business in California that have gross annual revenue over $25 million or meet data-volume thresholds, that consumers have a right to opt out of the sale or sharing of their personal information, and that a user-enabled global privacy control such as GPC must be honoured by covered businesses as a valid opt-out request. Businesses that sell or share data must also provide a “Do Not Sell or Share My Personal Information” link.

So for a US-only audience the requirement is not a consent banner at all. It is an opt-out mechanism, a working response to the GPC browser signal, and a notice at collection. Sites with EU, UK and US visitors typically serve consent banners by region and an opt-out link everywhere, which Consent Mode’s region-specific defaults make straightforward.

What regulators actually enforce

The gap between what the law says and what gets enforced is where most cookie banner decisions should be made, and in 2025 and 2026 that gap has narrowed.

The clearest data point is British. In the ICO’s December 2025 compliance update, the regulator reported that 979 of the UK’s top 1,000 websites met its compliance checks at their most recent test. Of those, 415 passed without any intervention; the other 564 improved after the ICO wrote to them, opened investigations, and in 17 cases issued preliminary enforcement notices.

The checks tested three things: whether advertising cookies were set before the user could choose, whether rejecting was as easy as accepting, and whether cookies were set after consent was refused. The ICO also noted that the consent platforms it engaged with serve nearly 80% of the top 500 sites and changed their defaults as a result.

Three tests, then, and they are the ones to design against. Nothing non-essential before the choice. Reject as easy as accept. Nothing after a refusal.

The EU enforcement pattern was driven by complaints rather than sweeps. noyb’s August 2022 complaint round lodged 226 GDPR complaints with 18 authorities against sites running OneTrust with deceptive settings, after which the vendor changed its default configuration. The taskforce report above was the authorities’ coordinated response to that campaign.

It is worth being honest about how much of the web is covered by any of this. The 2024 Web Almanac privacy chapter found an IAB TCF or USP consent framework on 5.8% of home pages, TCF v2 on 4.0%, and a compliant TCF v2 setup on 1.7%, while 95% of desktop sites contained at least one tracker and the Google Analytics cookie alone appeared on 49% of desktop pages. Enforcement has concentrated on the largest sites. That is not a reason to ignore the rules on a smaller one; it is a reason to expect the attention to spread.

Do you need a cookie banner at all?

Not necessarily, and the honest answer depends on what you load.

If your site sets only strictly necessary cookies (session, security, load balancing, the basket, the consent preference itself), no consent is required and no banner is required. You still have to tell people what you set, which a cookies page linked from the footer does.

If you run analytics and nothing else, the answer now differs by jurisdiction. In the UK, aggregate analytics used solely to improve the service can fall under the statistical purposes exception described above, provided you give clear information and a simple way to object. That is an objection control, not a consent banner, and the ICO suggests it can be a toggle that is on by default. Whether your analytics configuration actually meets the exception is the question to answer first: individual-level retention, user identifiers shared with advertising products, or any advertising measurement take you outside it. In the EU, analytics that touch the device still need consent unless a national authority has published its own exemption for a specific privacy-preserving configuration.

If you run advertising tags of any kind, you need consent in the EU and the UK, and there is no exception to reach for. If you serve California residents at the CCPA thresholds, you need an opt-out mechanism whatever else you do.

The audit that answers this is not glamorous: list every cookie, script and storage key the site sets, who sets it, and what for. It is one of the standing checks in a technical SEO audit methodology, because the same inventory catches third-party scripts you forgot were there.

Implementation: wire the banner to Consent Mode v2 first

If your site uses any Google tag, the cookie banner and Google’s consent mode are one system, and getting the wiring wrong is the most common way a compliant cookie banner destroys your data. What that wiring means for the smallest channel most sites have, AI referrals from EEA visitors who decline, is covered in Consent Mode v2 and AI referral traffic.

Google’s consent mode setup guide is specific about the order of operations. The default consent command has to run on every page before any command that sends measurement data. If the banner loads asynchronously, you set a wait time in milliseconds so tags hold until the banner has had a chance to update.

When the user interacts, you send an update immediately, persist the choice in first-party storage, and replay it on every subsequent page, because consent mode itself does not remember anything. Consent mode v2 added two parameters, one for sending user data to Google for advertising and one for ad personalisation, on top of the original storage flags. And the guide’s warning is worth quoting: if your consent code is called out of order, consent defaults won’t work.

Why this matters commercially is set out in Google’s EEA consent mode update. To keep using Google’s tags for measurement, personalised advertising and remarketing with EEA users, you must collect consent and share the consent signals with Google. The same page warns that if you prevent Google tags from loading until the user interacts with the banner, Google cannot verify consent choices and you may lose data. In other words, the older “block everything until they click” pattern is now the wrong pattern for Google tags: load the tag, run the denied defaults, and let consent mode gate what it sends. That is what unlocks the modelled data that fills the gap left by users who decline; setting it up properly is most of the work in the GA4 with Consent Mode v2 and server-side tagging engagements I run.

Two obligations tend to get missed because they sit in a policy rather than a developer guide. Google’s EU user consent policy requires that you retain records of the consent users give, provide clear instructions for revoking it, and identify each party that may collect or use personal data as a result of your use of a Google product. A banner that does not log its own decisions, or that names “partners” without listing them, fails the vendor’s terms before it fails any regulator’s.

Implementation: the banner itself

With the wiring right, the cookie banner has a short list of things to get right, and most of them come straight from the enforcement findings above.

Equal choices on the first layer. Accept and reject buttons of the same size, colour treatment and prominence, with a third route to granular settings. The ICO tested “as easy to reject as to accept” across the top 1,000 sites, and the EDPB taskforce treats a reject option hidden in a link as invalid.

No pre-ticked boxes, and per-category toggles. Categories off by default in the preferences layer; essential always on and labelled as such.

A permanent way back. A “Cookie preferences” link in the footer that reopens the preferences layer, so withdrawal is as easy as consent on every page.

Accessible by construction. The GOV.UK Design System cookie banner component is the best public reference I know. It places the banner before the skip link, tells you not to make it sticky so it cannot obscure focused content (WCAG 2.2 success criterion 2.4.11), shows a confirmation message with a role of alert and moves focus to it, and saves the preference for one year. If you need a starting point that has been through accessibility review, start there rather than with a vendor template.

Honest categorisation. The taskforce report flags cookies inaccurately classed as essential, and the ICO states that advertising purposes are never strictly necessary. If a category label would not survive a regulator reading the actual cookie, rename it.

Region awareness. Consent mode supports region-specific defaults, so a site can deny everything by default for EEA and UK visitors, honour GPC and offer an opt-out link for California, and behave differently elsewhere, from one implementation.

Implementation: performance and SEO

The part of cookie banner design that no compliance guide covers is that the banner is usually the first third-party script on the page and the first thing the user sees. Both have consequences.

web.dev’s cookie notice best practices describe the damage. Cookie consent notices are a very common source of layout shifts, because a banner inserted at the top of an already-rendered page pushes everything below it down. The Accept click is a frequent cause of high Interaction to Next Paint, because it triggers the loading of every third-party script at once. And notices from third-party providers generally cost more than a notice you build yourself.

The fixes from the same source: load the notice script asynchronously and directly in the document rather than through a tag manager, preconnect to its origin, reserve space for it or use a footer or modal placement that overlays rather than shifts, and expect a first-party notice to be cheaper than a vendor’s. If your Core Web Vitals field data shows a CLS problem you cannot find, the banner is the first suspect; how to measure and fix CLS and INP in code covers the diagnosis.

The same source makes a measurement point that catches teams out: analytics and real-user monitoring tools that depend on cookies cannot capture performance data from users who decline, so your Core Web Vitals sample skews towards accepters. Cookieless measurement libraries exist for exactly this reason.

On crawling and indexing, two Google documents settle the common worries. Google’s guidance on intrusive interstitials says that, unless they are legally mandatory, you should not obscure the entire page or redirect users to a separate page for consent; mandatory interstitials are exempt from the interstitial guidelines, but Google still recommends overlaying the content rather than replacing it, so it can index what is underneath, and never redirecting every URL to a single consent page, which removes everything but that page from search.

Google’s JavaScript troubleshooting guide states that its rendering service does not retain state across page loads: cookies and local storage are cleared, and Googlebot declines permission requests. The consequence is that Googlebot sees your banner on every single page, never consents, and never persists anything. A banner that hides content until consent is a banner that hides content from Google. The rendering mechanics are in how Google renders JavaScript.

How this site does it

This site runs a first-party cookie banner with no consent platform, wired to Google Tag Manager through Consent Mode v2. The implementation is a few dozen lines, and it is the pattern I would recommend to any site that does not need a vendor’s audit trail.

The default runs inline in the head, before anything else, denies every storage type except security, gives the banner half a second to update, and replays a saved choice from local storage if one exists:

window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  functionality_storage: 'denied',
  personalization_storage: 'denied',
  security_storage: 'granted',
  wait_for_update: 500
});
try {
  var saved = JSON.parse(localStorage.getItem('nm_consent_v1'));
  if (saved && saved.consent) gtag('consent', 'update', saved.consent);
} catch (e) {}

Tag Manager itself loads lazily, on first interaction or when the browser goes idle, which keeps roughly a quarter of a megabyte of analytics JavaScript off the critical path. That is safe because the consent default has already run, and any update the banner sends queues on the data layer until the container boots.

The banner has three buttons of equal weight on the first layer: Reject all, Customise, Accept all. The preferences layer has four categories, essential always on, analytics, marketing and personalisation off by default, each mapped to the consent mode flags it controls. Saving a choice writes it to local storage with a timestamp, sends the consent update, and pushes a named event to the data layer so tags that need to react can. The footer carries a “Cookie preferences” link that reopens the layer on every page, and the privacy policy lists every cookie and what it does.

The banner is a section with a region role rather than a fixed overlay, so it never obscures focused content, and the preferences dialog traps focus while open and returns it on close. It is rendered with the page’s own CSS, so it adds no request and reserves its own space, which is why it does not register as a layout shift.

What this buys in measurement terms is a GA4 property that tells the truth in both directions: consented sessions carry cookies, declined sessions still send cookieless pings that consent mode can model from, and the attribution work described in GA4 referral tracking degrades gracefully rather than silently. Reject rates are visible rather than hidden inside a traffic drop.

A checklist you can hand to a developer

Area	Requirement	How to check
Timing	No non-essential storage before the choice, none after a refusal	Load a page in a fresh profile and inspect cookies and storage before clicking anything, then after Reject
Choices	Accept and reject equally prominent on the first layer; granular layer available	Screenshot the first layer; both buttons should have the same visual weight
Defaults	Categories off by default; no pre-ticked boxes	Open the preferences layer without having consented
Withdrawal	Preferences reachable from every page; withdrawing as easy as consenting	Footer link present and functional site-wide
Consent mode	Defaults before tags, update on interaction, choice persisted and replayed	Tag Assistant shows the consent state on page load and after the click
Records	Consent decisions logged; revocation instructions provided; parties identified	Read the policy against the vendor list actually loading
Performance	No layout shift from the banner; async, direct script load	Lighthouse and field CLS with and without the banner
Crawlability	Content overlaid, not replaced or redirected	URL Inspection in Search Console shows the content in the rendered HTML
Accessibility	Not sticky over focused content; confirmation announced; keyboard operable	Tab through the banner and the dialog with a screen reader running
Regions	EEA and UK opt-in defaults; GPC honoured and opt-out link for California	Test with a VPN and with GPC enabled in the browser

Frequently asked questions

What is a cookie banner for?

A cookie banner exists to inform visitors that a site stores or reads information on their device and to obtain their consent before it does so for any non-essential purpose. The consent it collects has to be a clear positive action, freely given and specific, and the banner has to make refusing as easy as accepting. It is a consent mechanism first and an interface second.

Is it illegal to not have a cookie banner?

Not in itself. If a site sets only strictly necessary cookies, no consent and no banner is required, although you must still tell visitors what you set. In the UK, aggregate analytics used solely to improve the service can now run under a statistical purposes exception with an objection control rather than a consent banner. What is unlawful is setting non-essential cookies without a valid legal route, and for advertising cookies in the EU and UK the only route is consent.

What are the legal requirements for a cookie banner?

Under the EU and UK rules: clear and comprehensive information about what is set and why; no non-essential storage before the user chooses; consent given by a positive action, with reject as easy as accept and no pre-ticked boxes; per-purpose choices; a way to withdraw consent at any time that is as easy as giving it; and records of the decisions. Design details such as button colour are judged case by case, but a reject option that is hard to see or read is treated as invalid consent.

Is a cookie banner required in the US?

No federal law requires one. State privacy laws such as California’s CCPA are opt-out regimes: covered businesses must let consumers opt out of the sale or sharing of their personal information, must honour the Global Privacy Control browser signal as a valid opt-out, and must provide a “Do Not Sell or Share My Personal Information” link. A site serving both US and European visitors usually shows a consent banner by region and an opt-out mechanism everywhere.

Do I need a cookie banner for Google Analytics?

In the EU, yes: Google Analytics stores identifiers on the device and does not fall within the strictly necessary exception. In the UK, it depends on configuration: aggregate, improvement-only analytics with the provider acting as your processor can fall under the statistical purposes exception, but sharing user-level data with Google’s advertising products or running advertising measurement takes you back to consent. Either way, if you use Google tags with EEA users, Google’s own policy requires you to collect consent and pass the signals through Consent Mode v2.