Skip to main content

Cookie Consent Banners Done Right

privacy gdpr ccpa compliance web development
Cookie Consent Banners Done Right

Almost every website greets you with a cookie banner. Most of them are bad. Some are illegal. A surprising number break the law they were built to comply with.

This is a practical guide to getting cookie consent right in 2026: what GDPR and CCPA actually require, what regulators have been fining people for, and how to design a banner that doesn’t trash your conversion rate or your reputation.

What the laws actually say

We’ll keep this short because the legal details aren’t the interesting part.

GDPR (EU/EEA, UK) requires prior, informed, freely given consent for any non-essential cookies. “Non-essential” means anything that isn’t strictly necessary for the site to function. So analytics, marketing pixels, A/B testing, retargeting, and most third-party embeds all need consent before they load.

ePrivacy Directive is the EU’s cookie-specific rule. It’s what regulators usually fine you under, more than GDPR itself. The promised ePrivacy Regulation has been “imminent” for years and still isn’t done.

CCPA / CPRA (California) is a different beast. It’s opt-out, not opt-in, for most data sales and sharing. You need a “Do Not Sell or Share My Personal Information” link. As of 2026, similar opt-out frameworks are live in Virginia, Colorado, Connecticut, Utah, Texas, and a growing list of states, each with slightly different rules.

The practical implication: if your site has any non-EU and non-US traffic, you’re operating under at least two different legal regimes. A single banner can satisfy both, but you have to design it that way deliberately.

What “compliant” actually means in practice

A genuinely compliant GDPR banner does five things:

  1. Loads no non-essential cookies before consent. This is the one most sites get wrong. If your Google Analytics pixel fires before the banner appears, you’re already non-compliant. Doesn’t matter what the banner says afterward.
  2. Offers “Accept” and “Reject” with equal prominence. A big green “Accept All” and a tiny gray “Manage preferences” buried in a sub-menu is exactly what regulators have been fining.
  3. Lets users withdraw consent as easily as they gave it. A persistent “Cookie settings” link in the footer is the usual implementation.
  4. Categorizes cookies clearly. Necessary, analytics, marketing — with a way to accept or reject each.
  5. Records consent in a way you can prove later. Regulators have asked for proof. Most consent management platforms handle this automatically.

CCPA is mostly about the “Do Not Sell” link, a privacy policy update, and respecting Global Privacy Control (GPC) signals if your users send them. Browsers like Brave and Firefox send GPC in some configurations, and California explicitly requires you to honor it.

Dark patterns regulators have actually fined

This is the part worth memorizing. These have all resulted in real fines under GDPR:

  • “Accept All” prominent, “Reject All” hidden or requiring more clicks
  • Pre-checked boxes for non-essential cookies
  • Confusing button labels (“Continue” vs “Manage settings”)
  • Banners that block the page until consent is given, with no clear “Reject” option
  • “Pay or consent” walls where the only choice is paying or accepting tracking
  • Loading analytics or marketing scripts before consent is given (the silent killer)

The French CNIL has been particularly active. Google, Facebook, Amazon, and many smaller sites have all been fined for variants of these. The fines aren’t small.

A banner that works for users and regulators usually has:

  • Two equally-weighted buttons: “Accept All” and “Reject All”
  • A clear “Customize” or “Preferences” option for granular control
  • Plain-language descriptions of what each category does
  • No cookies fire until the user clicks something
  • A footer link to revisit consent any time

Crucially, this tends to convert better than dark-pattern banners. People who feel respected don’t bounce. People who feel manipulated do.

The “essential cookies” question

Not every cookie needs consent. “Strictly necessary” cookies — session management, CSRF tokens, shopping cart, login state, the cookie banner’s own preferences — are exempt.

What’s not exempt, despite what some vendors claim:

  • Analytics, even “anonymous” or “first-party” analytics. The ePrivacy Directive doesn’t have a “legitimate interest” exception for cookies. Audience measurement exemptions exist in some jurisdictions, but they’re narrow.
  • A/B testing tools
  • Marketing pixels
  • Heatmaps and session replay (these face extra scrutiny because of the data they capture)
  • Most embedded content — YouTube, Vimeo, Maps — which set their own cookies on load

Self-hosted, server-side analytics like Plausible (in basic mode), Fathom, or a custom log-based pipeline can be argued as cookie-less and consent-free. We’ve seen sites switch to these specifically to avoid the banner problem.

If you have more than a handful of third-party scripts, a CMP is worth the cost. Options worth knowing:

  • CookieYes — affordable, decent UX, good for SMBs.
  • Cookiebot — well-established, automatic scanning, more expensive.
  • OneTrust — enterprise, comprehensive, overkill for most sites.
  • Termly — bundled with policy generation.
  • Klaro — open source, self-hosted, no per-page-view fees.
  • Cookie Consent (Orest Bida) — free, open source, lightweight.

For a typical small business site, the free or low-cost options are fine. The expensive ones earn their cost when you’re managing dozens of jurisdictions and hundreds of scripts.

Implementing it yourself

If you want to do this without a CMP, the architecture is:

  1. Block all non-essential scripts from loading by default. Use a type="text/plain" placeholder or a tag manager that respects consent.
  2. Show the banner.
  3. On consent (full or partial), unblock the relevant scripts and load them.
  4. Persist the choice in a cookie or localStorage.
  5. On later visits, check the stored consent and load accordingly.
  6. Provide a “Manage cookies” link in the footer to re-open the banner.

The hardest part is step 1. Most sites that “implement consent” still leak scripts because some third-party widget loads via a different path. Test with the network tab open and a fresh browser profile.

If you use Google Analytics, Ads, or Tag Manager, Consent Mode v2 has been required for EU traffic since March 2024. It tells Google services whether the user consented, and they adjust behavior accordingly (less precise data, anonymized pings, modeled conversions).

Most CMPs integrate Consent Mode automatically now. If you’re rolling your own, the gtag('consent', ...) API is what you need.

The honest take

Cookie banners are a UX disaster that nobody likes — users, site owners, regulators, all of us. They exist because the industry kept building tracking infrastructure long after it was clear most users didn’t want it.

You have three roughly sensible strategies in 2026:

  1. Comply properly. Use a CMP, design a non-dark-pattern banner, accept the conversion cost of users who reject. This is what we recommend for most clients.
  2. Reduce dependence on cookies. Switch to cookie-less analytics (Plausible, server-side, log-based), self-host embeds, and shrink the banner to the legal minimum. Sometimes you can get to “no banner needed” entirely.
  3. Geo-target the banner. Show full consent UI to EU/EEA/UK and California traffic, skip it elsewhere. Legal but feels a little cynical, and the engineering cost isn’t always worth it.

There’s no clean answer. Pick the one that fits your audience and your data appetite.

A short checklist

Before declaring your banner “done”:

  • Open the network tab on a fresh profile. Are any non-essential cookies firing before consent?
  • Does “Reject All” take the same number of clicks as “Accept All”?
  • Is the “Reject All” button visually equal to “Accept All”?
  • Can a user withdraw consent later from a persistent link?
  • Is consent recorded with a timestamp and version of the policy?
  • Does it work without JavaScript, at least enough to inform the user?

If you’re not sure where your site stands, a privacy audit is usually a small investment that pays for itself the first time a regulator asks questions. Get in touch if you’d like a hand.

Need help shipping?

We help teams build and ship software that works. Performance, SEO, features, weekly demos, full ownership.

Get a Free Audit