The Numbers Don't Lie: Most Cookie Banners Are Still Broken

A 2025 analysis of roughly 10,000 EU websites found that 78% of cookie banners failed to meet the legal requirements for valid consent under GDPR and the ePrivacy Directive. That figure isn't surprising to anyone who's audited consent implementations at scale, but it should alarm anyone responsible for a website's privacy posture.

Cookie consent has been legally required in Europe since the ePrivacy Directive was amended in 2009 — over 16 years ago. The GDPR raised the bar further in 2018 by defining what valid consent actually looks like. And yet, the majority of banners on the web still don't clear it. Not because the law is unclear — the EDPB's guidelines on consent are unambiguous — but because the gap between "having a banner" and "having a compliant banner" is wider than most teams realise.

This article unpacks why so many banners fail, what regulators are actually looking for in 2026, and how to audit your own implementation against the current standard.

The Shift: From "Does It Exist?" to "Does It Actually Work?"

In the early years of GDPR enforcement, regulators largely focused on whether a cookie banner existed at all. Having something pop up was enough to avoid immediate scrutiny. That era is over.

The turning point came in 2021-2023, when data protection authorities across Europe began coordinated enforcement actions targeting the quality of consent, not just its presence. The EDPB's Cookie Banner Taskforce, established in 2021 and reporting results in 2023, examined hundreds of websites and identified specific, recurring failures. Their report was explicit: a banner that exists but doesn't produce valid consent is no better than no banner at all.

Regulators now evaluate cookie banners against a functional standard. They check whether the mechanism actually blocks cookies before consent, whether the reject option is genuinely accessible, whether the language is clear, and whether the consent record would hold up under audit. The question has shifted from "do you have a banner?" to "does your banner produce legally valid consent?"

This shift explains the 78% failure rate. Most of these sites have banners. The banners just don't work the way the law requires.

The Six Most Common Failure Modes

Non-compliant banners tend to fail in predictable ways. The 2025 study and prior EDPB taskforce findings converge on a set of recurring patterns. Here are the six most common.

1. No Reject Button on the First Layer

The single most frequent failure. Many banners present an "Accept all" button on the first screen but force users to navigate into a secondary "Manage preferences" screen to refuse. Under EDPB guidance and multiple national regulator decisions, refusing cookies must be as easy as accepting them. The French regulator CNIL has been particularly aggressive here — its December 2021 enforcement against Google (€150 million) and Facebook (€60 million) specifically cited the absence of an equally prominent reject option.

The requirement is clear: if "Accept all" is a single click on the first layer, "Reject all" must also be a single click on the same layer. Hiding it behind a second screen, a smaller font, or a less prominent position is non-compliant.

2. Dark Patterns in Button Design

Even when a reject button exists, many banners use visual design to steer users toward acceptance. Common dark patterns include:

Making the accept button a bright, high-contrast colour while the reject button is greyed out or outlined
Placing the accept button in the dominant visual position (left or top in LTR layouts) and the reject button in a less prominent spot
Using affirmative language for acceptance ("Yes, I agree!") and negative framing for rejection ("No, I want a degraded experience")
Making the close/X button behave as implicit acceptance

Regulators have been explicit that these patterns violate the "freely given" requirement of GDPR consent. The EDPB's cookie banner taskforce report specifically flagged asymmetric button styling as non-compliant. For a deeper look at what's now prohibited, see our guide on dark patterns in cookie banners.

3. Pre-Checked Consent Boxes

The CJEU's Planet49 ruling (Case C-673/17, October 2019) settled this definitively: a pre-ticked checkbox does not constitute consent because consent requires a "clear affirmative action." Despite this, pre-checked boxes persist — particularly in preference centres where analytics or functional categories default to "on."

The same logic applies to "consent by scrolling" or "consent by continuing to browse." Both treat inaction as agreement, which contradicts GDPR Article 4(11). If your banner interprets page interaction as consent without an explicit opt-in action, it fails.

4. Confusing or Misleading Language

Consent must be "informed," which means the user needs to understand what they're agreeing to. Common language failures include:

Vague purpose descriptions like "improving your experience" without specifying what data is collected or by whom
Walls of legalese that discourage reading
Mislabelling tracking cookies as "strictly necessary" to avoid needing consent
Claiming cookies are needed "for the site to function" when they're actually marketing pixels

If a user can't understand what each cookie category does from the language presented, the "informed" element of consent is missing.

5. Cookies Set Before Consent

This is the most technically consequential failure. Under the ePrivacy Directive, non-essential cookies must not be stored on the user's device until consent is obtained. Many implementations fire analytics tags, advertising pixels, and third-party scripts the moment the page loads — before the consent banner is even rendered, let alone interacted with.

This happens for several reasons: tag managers configured to fire on page load by default, third-party scripts that self-initialise, or CMPs that only control visibility of the banner rather than actually gating script execution. The result is that consent is cosmetic — the banner asks for permission, but the tracking has already occurred. See how to block scripts until consent for correct implementation approaches.

6. No Easy Way to Withdraw Consent

GDPR Article 7(3) requires that withdrawing consent be as easy as giving it. Many sites make it trivially easy to accept cookies (one click) but provide no obvious way to change that choice later. The floating re-open button or footer link that lets users revisit their preferences is missing from a significant number of implementations.

Without it, consent is effectively irrevocable — which means it was never valid in the first place.

The Equal Prominence Rule and One-Click Reject

The requirement that has caught the most sites off guard is what practitioners call the "equal prominence" rule. It isn't a single regulation but a convergence of guidance from the EDPB, CNIL, and other DPAs that has hardened into a de facto standard.

The rule has two components:

One-click reject: If a user can accept all cookies in a single action on the first banner layer, they must also be able to reject all cookies in a single action on the same layer. A reject option buried in a secondary preferences panel doesn't count.
Visual parity: The reject option must have equal visual prominence to the accept option. Same size, same visual weight, comparable styling. A bold green "Accept" button next to a grey text link labelled "Manage" fails this test.

CNIL has been the most explicit enforcer: its updated cookie guidelines require that "the mechanism for refusing must be accessible on the same level, and presented in a similar manner" as the acceptance mechanism. Other DPAs, including Italy's Garante and Spain's AEPD, have issued consistent guidance.

This doesn't mean your design has to be ugly. You can still make a thoughtful, branded consent UI — you just can't weaponise design to funnel users toward acceptance. Our cookie banner design best practices guide shows how to build compliant layouts that still convert well.

Enforcement: Real Fines, Real Consequences

Cookie consent enforcement is no longer hypothetical. Landmark actions that define the current landscape:

Google (€150M) and Facebook (€60M), CNIL, January 2022: Fined for making cookie rejection harder than acceptance — users could accept in one click but needed multiple clicks to refuse.
Google (€100M) and Amazon (€35M), CNIL, December 2020: Fined for dropping advertising cookies without prior consent.
Microsoft Ireland (€60M), CNIL, December 2022: Advertising cookies deposited without consent on bing.com.
TikTok (€5M), CNIL, January 2023: Cookie rejection required more clicks than acceptance.
EDPB Cookie Banner Taskforce, 2023: Coordinated review across multiple DPAs, resulting in 350+ complaints and corrective actions.

Fines are increasing, coordinated enforcement is expanding, and smaller organisations are increasingly targeted — not just the tech giants that make headlines.

Technical Requirements: What "Compliant" Actually Means at the Code Level

A compliant cookie banner isn't just a UI component — it's a technical control system. Here's what needs to happen at the implementation level.

Cookie Blocking Before Consent

Non-essential scripts must not execute until the user grants consent. Approaches include script type rewriting (changing text/javascript to text/plain and re-enabling after consent), consent-aware triggers in Google Tag Manager, and server-side conditional script inclusion.

The critical test: load your site in a fresh browser, open the network inspector, and observe what fires before you interact with the banner. If you see requests to analytics or advertising endpoints, you have a compliance gap. See our comparison of how different CMPs block scripts for implementation specifics.

Correct Consent Mode Signals

If you use Google tags (GA4, Google Ads, Floodlight), your consent implementation needs to emit correct Consent Mode v2 signals. This means:

Setting analytics_storage, ad_storage, ad_user_data, and ad_personalization to denied by default
Updating these signals to granted only when the user explicitly consents to the corresponding purpose
Firing the consent update before the tag fires, not after — ordering matters
Ensuring that a consent withdrawal triggers a reset to denied

Advanced Consent Mode (as opposed to Basic) enables Google's behavioural modelling to fill data gaps from non-consenting users, but only if your signals are correctly structured. Sending incorrect signals — or worse, hardcoding everything to granted regardless of actual consent — undermines both compliance and data quality. For how this affects your analytics, see how Consent Mode affects GA4 reporting.

Consent Record Storage

You need to demonstrate that consent was obtained. Store a record including: the timestamp, the banner version the user saw, per-purpose choices (not just a single boolean), and a consent ID. If a regulator asks you to prove that a specific user consented to marketing cookies on a specific date, you need to produce that record.

Self-Audit Checklist: 12 Points to Verify Right Now

Use this checklist to evaluate your current cookie banner implementation. Each item maps to a specific regulatory requirement. A failure on any single point can render your consent mechanism non-compliant.

No cookies before consent: Load your site in a clean browser session. Open DevTools → Application → Cookies. Before interacting with the banner, are any non-essential cookies present? If yes, you're non-compliant.
First-layer reject button: Does your banner's first screen include a clearly labelled "Reject all" or equivalent button? If users must navigate to a second screen to refuse, it fails the one-click reject requirement.
Equal visual prominence: Compare the accept and reject buttons. Are they the same size, similar visual weight, and comparable styling? A bright accept button next to a subdued reject link fails.
No pre-checked boxes: Open your banner's preferences panel. Are any non-essential categories toggled on by default? They must all default to off.
Clear purpose descriptions: Read your banner's category descriptions. Can a non-technical user understand what each category does and who receives the data? Vague language like "enhance your experience" isn't sufficient.
Correct cookie categorisation: Review what's labelled "strictly necessary." Are analytics, marketing, or social media cookies hidden in this category? Mislabelling a cookie to avoid consent requirements is a common audit finding.
Consent withdrawal mechanism: After accepting cookies, can you easily find a way to change your preferences? There should be a persistent UI element (floating button, footer link) that reopens the consent dialogue.
Consent records: Does your CMP store a verifiable record of each consent action, including the timestamp, banner version, and per-purpose choices? Can you retrieve it if asked?
Consent Mode signals: If you use Google tags, verify that analytics_storage and ad_storage default to denied and update to granted only after explicit consent. Check in GTM's preview mode or via the dataLayer.
Cookie inventory accuracy: When was your last cookie scan? Does the list of cookies in your banner match what your site actually sets? Third-party scripts change their behaviour; a scan from six months ago may be stale.
Consent expiry and re-consent: How long does a consent choice persist before you re-ask? Regulators generally expect re-consent within 6-13 months. Check that your implementation handles consent expiry correctly.
Close/dismiss behaviour: What happens when a user clicks the X or clicks outside the banner? If this is treated as consent, you're non-compliant. Dismissal without an affirmative action must result in cookies remaining blocked.

Why Manual Audits Fall Short

Running through the checklist once is a good start, but websites are dynamic. Marketing teams add tags, A/B testing tools introduce scripts, and third-party widgets update their cookie behaviour — often without anyone on the privacy team knowing. A banner that's compliant today can drift within weeks.

Continuous scanning catches what point-in-time audits miss: new uncategorised cookies, scripts firing before consent, misconfigured Consent Mode signals, and changes in third-party behaviour. See how cookie scanners work for the technical detail on deep scanning vs. surface-level checks.

How CookieBeam's Automated Scanning Catches These Issues

CookieBeam's scanner is built to catch the failure modes described above — automatically and continuously.

Pre-consent cookie detection: The deep scanner loads your site in a real browser, captures every cookie, script, and outbound connection that fires before any consent interaction, and flags anything that shouldn't be there. This catches the "cookies before consent" problem that manual testing misses — especially when third-party scripts behave differently across page loads.

Script and connection inventory: Every script and third-party connection is catalogued and matched against known tracker databases. New scripts surface as uncategorised items requiring review before they become compliance gaps.

Consent Mode verification: CookieBeam validates that your Consent Mode signals are correctly structured and fire in the right order relative to your tags.

Drift detection: Client-side drift detection monitors for new connections and scripts between scheduled scans. When a drift threshold is hit, the new tracker is automatically flagged.

Continuous monitoring: Scheduled scans keep your cookie inventory current as your site evolves — the difference between knowing your site was compliant last month and knowing it's compliant now.

Moving From "Banner Exists" to "Banner Works"

The cost of non-compliance extends beyond direct fines. Consent collected through a non-compliant mechanism can be invalidated retroactively — meaning data processed under it may need to be deleted. Incorrect Consent Mode signals make your GA4 and Google Ads data unreliable. And DPA enforcement decisions are public, signalling weak data governance to customers and partners.

The 78% non-compliance rate means most of the web is running this risk. The gap is technical, not conceptual — teams know they need consent but haven't verified their implementation actually delivers it.

Closing that gap requires three things: understanding what regulators actually check (not what you assume they check), auditing your implementation against that standard, and putting continuous monitoring in place to prevent drift. The checklist in this article gives you the audit framework. The enforcement examples show you the consequences of ignoring it.

If you haven't tested your banner against this checklist recently, now is the time. Open a clean browser session, load your site, and see what happens before you click anything. The answer might surprise you.