Cookie Consent Examples That Actually Comply

You just installed a consent plugin. Maybe CookieYes, maybe Complianz, maybe something your theme bundled in. The default banner is sitting on your homepage right now, and you're staring at it wondering three things: does the wording actually work, does it need a reject button, and did you just create more legal risk by turning the thing on.

Fair questions, and searching for "cookie consent examples" mostly gets you screenshot galleries from companies selling you a banner tool. Pretty pictures, no regulator citations, no text you can paste.

This article does the opposite. Every example below is graded pass, borderline, or fail against what regulators have actually published: the European Data Protection Board's own taskforce report, the UK Information Commissioner's Office guidance, and France's CNIL. Each one comes with a wording sample you can adapt.

One quick note before we start: the banner itself is governed by ePrivacy rules (in the UK, the Privacy and Electronic Communications Regulations, or PECR), while what happens to any data collected afterward falls under GDPR. Two laws, working together, and the wording below is built to satisfy both.

Cookie Banner Examples, Graded Pass to Fail

The three things regulators check first

The UK's ICO spent much of 2025 sweeping the country's 1,000 most-visited websites. By December, 979 passed. Of those, 564 only got there after the ICO stepped in directly, and 17 sites are now facing preliminary enforcement notices (ICO, 4 December 2025).

What did the regulator actually test? Three things, and they're the same three things worth checking on your own site before you check anything else.

First: nothing non-essential fires before the visitor clicks anything. No advertising pixel, no analytics tag, sitting in the page's response headers the moment the page loads.

Second: rejecting cookies takes the same number of clicks as accepting them. Not one click for "yes" and three menus deep for "no." Third: a refusal actually sticks. If someone declines and the same trackers reappear on the next page load, the banner was decoration, not consent.

Keep those three in your head. Every example below either satisfies them or breaks one, and I'll tell you which.

Think of a cookie banner the way you'd think of a bouncer at a door. A bouncer who lets everyone in before checking IDs isn't doing the job, no matter how official the uniform looks. The patterns below range from bouncers who check IDs properly to bouncers who wave everyone through while pretending otherwise.

Pass: the two-button banner that shows everything up front

This is the simplest pattern that actually works. One sentence explaining why cookies are used, two buttons of equal size and equal visual weight, a link to the full policy. Nothing hidden behind a second screen.

We use cookies to run this site and, with your permission, to understand how visitors use it. You can change your mind anytime from the link in our footer. Read our full Cookie Policy.

[ Accept all ]   [ Reject all ]

Why it passes: "Accept all" and "Reject all" are the same button style, same size, sitting side by side. Nobody has to hunt for the "no" option or squint at grey text to find it. That single design choice is what the EDPB's cookie banner taskforce flags most often when it condemns other banners, so getting it right here does most of the compliance work in one move (EDPB taskforce report, 2023).

Pass: the three-button banner with a real settings layer

Bigger sites usually need more than an all-or-nothing choice, because they're running separate analytics, advertising, and embedded-video cookies. A third button opens a settings panel where each category can be switched independently, and critically, every non-essential toggle starts switched off.

We'd like to use cookies to improve your experience. Choose what you're comfortable with below.

[ Accept all ]   [ Reject all ]   [ Manage choices ]

--- second layer ---
Necessary (always on): keeps the site working, remembers your cart, keeps you logged in.
Analytics (off): helps us see which pages get used.
Advertising (off): lets us show relevant ads on other sites.
Functional (off): remembers preferences like your language.

[ Confirm choices ]

Why it passes: every switch that isn't strictly necessary defaults to off, which is the actual legal standard, not a nice-to-have. GDPR's Recital 32 states plainly that "silence, pre-ticked boxes or inactivity should not therefore constitute consent" (GDPR, Recital 32). A toggle that starts on is a pre-ticked box wearing a different outfit. Each toggle usually maps to a technical setting too: analytics and advertising cookies often need the SameSite=None attribute to keep working inside embedded or cross-site contexts, which is a separate but related detail worth getting right; our SameSite cookie attribute guide covers when Lax, Strict or None actually applies.

Pass: the honest "we don't use cookies" notice

If your site genuinely only sets strictly necessary cookies (a session cookie, maybe a cart, nothing that tracks anyone across visits), you don't need a consent mechanism at all. You need a short, honest notice.

This site only uses cookies that are necessary for it to work (like keeping your session active). We don't use tracking, analytics, or advertising cookies.

Why it passes, with a catch: this only works if it's true. I've seen site owners paste this exact notice while Google Analytics is quietly running in the background, because they added an analytics plugin months after writing the banner and forgot to update the text. Analytics cookies are not strictly necessary, full stop, and a notice that claims otherwise is worse than no notice at all. If you're not sure what your site actually sets, understanding the difference between first-party and third-party cookies is a good place to start before you publish a notice like this one.

Borderline: accept now, reject two clicks away

This one shows up constantly, and it's the pattern that put most of that ICO sweep's 564 "improved after intervention" sites on the list in the first place: a big "Accept" button on the first screen, with reject buried inside a "Settings" link that most visitors never click.

[ Accept ]   [ Settings ]

Why it's borderline rather than a flat fail: the EDPB taskforce found that "a vast majority" of the data protection authorities it surveyed consider a missing first-layer reject option to be an infringement, but notes a few did not treat it that way (EDPB taskforce report, para 8). That's not a green light. The ICO and CNIL are firmly in the "vast majority" camp, and this exact pattern, a prominent accept button with reject buried a click deeper, is the single most common finding in every regulator sweep published since. If your reject button requires a second click your accept button doesn't, fix it.

Fail: reject disguised as a text link

By using this site, you agree to our use of cookies to improve your experience and show relevant content. [Learn more]

[ I Accept ]

Somewhere in that "Learn more" text, three paragraphs down, sits a sentence saying visitors can also decline. Why it fails: the EDPB taskforce specifically calls out a reject option "embedded in a paragraph of text" or "placed outside the cookie banner" as failing to produce valid consent (EDPB taskforce report, para 14). In December 2024, France's CNIL issued formal notices to several publishers for exactly this pattern, naming the specific tricks: reject shown as a plain link while accept gets a full button, mismatched font sizes, reject buried in body text (CNIL, 12 December 2024). Its own line on the matter: "rejecting cookies should be just as easy as accepting them."

Fail: "by continuing to browse, you accept cookies"

This site uses cookies. By continuing to browse, you accept our use of cookies.

[ Got it ]

There's no reject option here at all, just an acknowledgment button. Why it fails: this is implied consent through inaction, and GDPR's Recital 32 rules it out directly, along with the ICO's own guidance stating flatly that "silence or inactivity doesn't qualify" as consent. Scrolling isn't a decision. Clicking "Got it" isn't a decision either, since there's nothing to disagree with.

Fail: a settings layer with the toggles already on

--- second layer ---
Analytics (on)
Advertising Partners (on)
Legitimate Interest Partners (on)

[ Save preferences ]

Why it fails: this is the modern version of the pre-ticked checkbox, and it's already been tested in court. In the CJEU's Planet49 ruling, judges found that consent given by deselecting a pre-checked box isn't valid consent at all, because nothing about it is an active, freely given choice (CJEU, Planet49, Case C-673/17). The "legitimate interest" toggle is a particularly sneaky variant. It sounds like a separate legal basis a site can rely on instead of asking, but when it ships defaulted to on, the visitor effectively has to refuse twice, once for consent-based tracking and again for the legitimate-interest version of the same thing.

The US variant: no pop-up, just an opt-out link

Worth flagging separately, because it confuses a lot of site owners who read GDPR advice and assume it's universal: California's Consumer Privacy Act doesn't require a cookie pop-up at all. If a business sells or shares personal information, it needs a clearly visible "Do Not Sell or Share My Personal Information" link, and it must honor the Global Privacy Control browser signal as a valid opt-out (California Attorney General, CCPA).

Do Not Sell or Share My Personal Information

Why this isn't a fail in California: CCPA is opt-out by design, GDPR-style consent is opt-in. A US-only site with no EU or UK visitors doesn't need the accept/reject banner pattern at all. If your traffic includes European visitors, though, you need the opt-in version regardless of where your business is registered, because ePrivacy and GDPR apply based on where the visitor is, not where the server sits.

Check your own banner in two minutes

Reading examples only gets you so far. At some point you want to know what your own site is actually doing, and that's a two-part check.

Start with cookiecheck.tools. Paste in your URL and it fetches the page the way a first-time visitor's browser would, before anything gets clicked. It reports which cookies the server set on that very first response, flags missing Secure or HttpOnly attributes along the way (our guide to HttpOnly and Secure cookie flags explains what those protect against), flags a tracking_before_consent finding if an analytics or advertising cookie showed up before any consent choice was made, checks whether a recognized consent platform is present, and looks for a working link to your cookie policy.

It's a useful first pass, and it's honest about its limits: a static fetch can't see a banner that only loads from a JavaScript bundle, or cookies a script writes after the page settles. That's why a missing-CMP finding is flagged as a warning rather than a hard error.

Second, open your own site in a normal browser tab, click Reject, then check your browser's developer tools (or the report page again) to see whether anything you didn't consent to is still sitting there, especially a long-lived persistent cookie that outlives the session it was set in (see our session cookie vs persistent cookie guide for why that distinction matters here). That combination, a static check plus a manual click-through, catches almost everything a beginner setup gets wrong. Neither step hands you a legal verdict. Both steps tell you exactly what's happening, which is usually the harder half of the problem.

A quick checklist before you publish

Reject and Accept are the same size, same style, same number of clicks.
Nothing non-essential fires before a choice is made (a Content-Security-Policy in report-only mode will show you every third-party script that tries).
Every optional toggle defaults to off, including anything labeled "legitimate interest."
The banner links to your full cookie policy, not just a "learn more" that goes nowhere.
Refusing actually removes the cookies, not just hides the banner.
If you have EU or UK visitors and run Google Analytics, it sits behind the consent choice.
If you're US-only and sell or share data, you have a working Do Not Sell or Share link.
You've tested with a browser's dev tools open, not just by trusting the plugin's default settings.

None of this needs to be complicated. It needs to match what the visitor actually sees and clicks, which is the one thing a screenshot gallery can't check for you.

Frequently Asked Questions

What should a cookie consent banner say?

A compliant banner names what gets stored, explains why in plain language (not just "to improve your experience"), says whether any third party receives the data, and tells the visitor how to change their mind later. A short version works for simple sites: one sentence plus Accept and Reject buttons. Sites running analytics or ad cookies usually need a second layer that names each category (Necessary, Analytics, Advertising, Functional) so visitors can choose per category instead of all-or-nothing. Either way, the banner should link out to your full cookie policy page rather than trying to explain everything in the popup itself.

Is a reject button required on a cookie banner?

In the EU and UK, yes, and it needs to sit on the same first screen as the accept button, not buried a click deeper. The EDPB's cookie banner taskforce found that a vast majority of European data protection authorities treat a missing first-layer reject option as an infringement, and the ICO's own guidance says its consent mechanism must make it "as easy to refuse consent as it is to accept." A small number of authorities didn't treat this as a strict requirement in the taskforce's own survey, so it isn't unanimous across every jurisdiction, but the regulators most likely to actually enforce against a small site, the ICO and CNIL among them, are both firmly on the "required" side.

Can a cookie banner have pre-ticked boxes?

No. GDPR's Recital 32 states that silence, pre-ticked boxes, or inactivity don't count as valid consent, and the CJEU's Planet49 ruling confirmed that consent obtained by requiring someone to uncheck a pre-checked box isn't freely given consent at all. Every optional toggle on your settings screen, including newer "legitimate interest" switches that some plugins default to on, needs to start switched off. The visitor has to actively turn something on for it to count as a choice.

Do I need a cookie banner for Google Analytics?

In the EU and UK, yes, in almost every practical case. Google Analytics sets cookies used to measure and distinguish visitors, which puts it outside the "strictly necessary" exemption that lets some cookies run without consent.

France's CNIL runs a narrow audience-measurement exemption, but it requires strict first-party-only scope and no cross-site matching, and CNIL's own guidance states that most large analytics tools, standard Google Analytics setups included, don't meet those conditions. The UK's newer statistical-purposes exception (in force since February 2026) has similar conditions and doesn't specifically confirm Google Analytics qualifies.

Google's Consent Mode, worth noting separately, doesn't replace a banner either. Google's own developer documentation is explicit that Consent Mode doesn't obtain consent by itself, a banner or consent platform still has to do that job. The safe, simple answer for a beginner: put Google Analytics behind the consent choice, not in front of it.