GDPR Cookies Popup: What the Law Actually Requires From Your Site

You installed a gdpr cookies popup, maybe a full gdpr cookies banner with toggles for every tracker category, because a plugin nagged you into it or a client asked "are we covered?" and you didn't have a confident answer. Here's what surprises most site owners: GDPR and cookie consent get talked about as one rule, but they're two separate systems doing two separate jobs, and plenty of sites running a banner still fail because nobody worked out where one law ends and the other begins.

This is the obligations list, rule by rule, written for the person who has to make the banner actually work.

Two Laws, One Popup: Who Actually Owns This Rule

Think of it as two layers stacked on top of each other. The bottom layer is the ePrivacy Directive (2002/58/EC, amended in 2009), specifically Article 5(3). It governs one narrow, mechanical act: storing something on a visitor's device, or reading something already stored there, cookies, localStorage, pixels, fingerprinting scripts, all of it. That act needs consent unless it's strictly necessary for a service the user actually asked for, or purely for carrying a message across the network.

GDPR sits on top of that. It doesn't legislate cookies directly, Recital 30 just notes that cookie identifiers can make someone identifiable. What GDPR contributes is the definition of what "consent" has to look like: Article 4(11) calls it "freely given, specific, informed and unambiguous," backed by "a statement or a clear affirmative action." So ePrivacy is the law that made asking mandatory, and GDPR is the law that decides whether the asking was done properly. Get that split straight and the rest of this article falls into place.

The rules your cookie banner has to follow

None of these are guesses. Each one traces back to the EDPB's Guidelines 05/2020 on consent or the Cookie Banner Taskforce report the same regulators published in 2023. I've paired each rule with what it means in practice and a quick way to check your own site against it.

Rule 1: nothing non-essential fires before the click

The clearest, most litigated rule of all: if a cookie needs consent, it cannot be set until consent is given. Not "loaded but paused." Not "set, then deleted if they refuse." Set, full stop, only after the click.

This is exactly what tripped up Shein. CNIL's September 2025 decision (EUR 150 million) found that advertising cookies were dropped "as soon as" visitors arrived, and kept being placed and read even after someone clicked "Refuse all." Google's CNIL fine the same week, EUR 325 million, involved cookies set at account creation before any valid consent existed. Two of the largest cookie fines on record, and both came down to timing, not banner design.

What this means for your site: analytics, ad pixels, and social embeds cannot fire on page load if they aren't strictly necessary. How to check: open a private browsing window, open DevTools before the page loads, and watch the Network and Application tabs for anything setting cookies before you've clicked a thing.

Rule 2: consent means an action, not a scroll

Scrolling the page, closing the banner with an X, or simply continuing to browse does not count as consent under any reading regulators currently accept. The EDPB guidelines are blunt about it: scrolling or swiping "will not under any circumstances satisfy the requirement of a clear and affirmative action." Pre-ticked boxes fail the same test, and the CJEU said so directly in the Planet49 case in 2019, whether or not the cookie touches personal data.

What this means for your site: if your consent platform treats "user kept browsing" as implicit acceptance, that's not consent, it's a liability. How to check: read your platform's default behavior in its documentation, then confirm in DevTools that nothing changes in the cookie jar until a button is actually pressed.

Rule 3: reject has to be as easy as accept

This is the rule most sites still get wrong, often on purpose. If "Accept All" sits on the first screen as a big colored button and "Reject" requires two more clicks through a settings panel, that's an infringement in the view of "a vast majority" of European data protection authorities, per the taskforce report. The UK's ICO agrees: after writing to 53 of the UK's top 100 sites in late 2023 about buried reject options, 38 had fixed their gdpr cookies banner within about ten weeks. To see what a compliant layout looks like, our cookie consent banner examples post walks through real ones.

What this means for your site: reject and accept belong on the same layer, same visual weight. How to check: count the clicks to reject and the clicks to accept. If they're not equal, they're not compliant.

Rule 4: no cookie walls

A cookie wall blocks access to the page entirely unless the visitor accepts tracking. The EDPB guidelines address this directly: access to a service "must not be made conditional on the consent of a user to the storing of information." Consent given under that kind of pressure isn't freely given, and "freely given" is the first phrase in GDPR's own definition of consent.

What this means for your site: visitors need a real way to say no and still read your content. How to check: click reject and confirm the page still loads normally, no forced redirect, no grayed-out content sitting behind the banner.

Rule 5: tell people what and why, per purpose

Article 5(3) requires "clear and comprehensive information" before consent, and GDPR Article 13 adds its own transparency duties on top. A banner that says "we use cookies to improve your experience" tells the visitor almost nothing. What it needs to say, ideally broken out by category, is who is setting what, for how long, and for what purpose.

Rule 6: withdrawal is always one click away

GDPR Article 7(3) is explicit: withdrawing consent has to be "as easy as" giving it. The taskforce report translates that into a concrete expectation: an always-reachable icon or link that lets a returning visitor change their mind without digging through a footer or a settings page buried three clicks deep.

What this means for your site: if your only "change your mind" option is clearing cookies manually in browser settings, that's not withdrawal, that's a workaround. How to check: come back to your own site a week later and time how long it takes to find the opt-out.

Rule 7: analytics is not "essential"

This is the mislabel that catches the most sites. Session cookies, cart cookies, load-balancing cookies, and authentication cookies can usually skip the consent step because the visitor explicitly asked for the functionality they support. Analytics doesn't get to ride along under that label. The taskforce report calls mislabelling analytics as "essential" an infringement on its own, and it puts the burden of proof on the site owner to demonstrate essentiality, not assume it.

What this means for your site: if your analytics cookie sits in the "necessary, always on" bucket of your consent tool, move it. How to check: run your homepage through cookiecheck.tools and look at what the report flags as set before consent versus what's genuinely exempt.

Which cookies are exempt from consent

The exemption list hasn't moved much since the Article 29 Working Party laid it out in 2012, and it's narrower than most consent tool defaults suggest.

Two footnotes worth knowing. A cookie that does one exempt job and one tracking job needs consent for the whole cookie, you can't split it in half. And the UK carved out a narrower exception of its own: the Data (Use and Access) Act 2025 lets first-party, aggregate-only analytics run without consent under PECR, provided visitors are told about it and given a simple way to opt out, from early 2026. That exception lives in UK law, not EU law, so a site serving both audiences needs two different answers to "does analytics need a click first."

Can you load analytics before the visitor accepts?

In the EU, no. Analytics falls outside the exemption list above, so under a strict reading of ePrivacy Article 5(3), the script waits for the click. That's a real cost: teams running Google Consent Mode routinely tell me their first pageview data looks thinner because the tag was still waiting when the visitor bounced. That's the tradeoff the law makes, not a bug in your setup.

Google's Consent Mode gives you two ways to handle the wait. Basic mode blocks Google tags entirely until consent is granted. Advanced mode loads the tags immediately but keeps them in a reduced state, sending "cookieless pings" that carry coarse signals like browser type, screen size, and a rough IP-based location, even after someone declines.

Whether that ping counts as "access to information stored on the device" under Article 5(3) is genuinely contested, and the EDPB's 2023 guidelines on the technical scope of the rule lean toward reading it broadly. I won't tell you advanced mode is compliant or isn't, because nobody can say that with certainty right now. If you want the safer reading, basic mode or full blocking until consent is the more defensible default.

Does GDPR actually require a popup?

Not by name. GDPR never mentions cookies or popups. The obligation to ask before storing anything non-essential comes from ePrivacy Article 5(3); GDPR only supplies the definition of what a valid "yes" looks like once you're asking.

A site that sets nothing but strictly necessary cookies, no analytics, no ad pixels, no third-party embeds, technically doesn't need a popup at all. In practice almost no site clears that bar once you count the analytics tag and the embedded video player. If you're trying to work out which of your own trackers trigger that requirement, our piece on third-party cookies and when to block them breaks down which ones count.

What's changing (and what isn't) through 2026 and beyond

Two pieces of news get cited constantly, and both are easy to misread. First, the European Commission withdrew its long-stalled ePrivacy Regulation proposal in 2025, with the formal withdrawal published in the Official Journal in October. That means the 2002 Directive, old as it is, remains the governing law. Second, the Commission's November 2025 "Digital Omnibus" proposal would fold cookie consent into GDPR itself as a new Article 88a, with exemptions for a site owner's own audience measurement and security purposes, a mandatory one-click reject, and a six-month cooldown before re-asking a visitor who already said no.

None of that is law yet. It's a proposal moving through trilogue negotiations between the Commission, Council, and Parliament, and even under an optimistic timeline it wouldn't apply before 2027. Build your current setup around the rules above, not around a headline about banners "ending soon."

Check your own site in five minutes

You don't need a compliance consultant to get a first read on your own setup, though a static check can only see so much. Here's the gdpr cookies checklist I run at the start of every audit:

• Open a fresh private browsing window, no extensions, no cached session.
• Open DevTools before the page finishes loading, watch the Network tab for third-party requests and the Application tab for cookies appearing before any click.
• Click reject, then check the same tabs again. Nothing new should appear, and nothing that was already there should still be readable.
• Run the URL through cookiecheck.tools and read the Consent and Trackers sections, they flag cookies set before consent, mismatched signals, and known ad or analytics hosts by category.
• If you control the server config, check that session and auth cookies carry Secure and HttpOnly flags plus an appropriate SameSite value. That part of the fix lives at the server layer, and htaccess.tools covers setting those flags directly in your Apache config if you're not handling them in application code.

One honest limit worth naming: a static fetch can't see cookies that JavaScript sets after the page loads, or tags injected through a tag manager once a condition fires. That's why the browser-side check matters as much as the server-side scan. Neither one hands you a "compliant" stamp. What they hand you is evidence, the same evidence a regulator would look at first.

Frequently Asked Questions

Does GDPR require a cookie popup?

Not by name. GDPR never mentions cookies or popups directly; the obligation to ask before storing non-essential data on a device comes from the ePrivacy Directive's Article 5(3). GDPR's role is defining what counts as valid consent once you're asking. A site that sets only strictly necessary cookies technically doesn't need a banner, but almost every site running analytics, ads, or embedded widgets falls outside that narrow exemption.

Which cookies are exempt from consent under GDPR?

Cookies strictly necessary for a service the visitor asked for: shopping cart contents, login and authentication sessions, load-balancing, single-session UI preferences like language, and security or fraud-prevention cookies. This list traces back to the Article 29 Working Party's 2012 opinion (WP194) and hasn't changed materially since. Analytics, advertising, retargeting, and social plugin tracking all sit outside it and need consent, first-party or third-party; mislabelling either one as "essential" is treated as an infringement in its own right.

Can I load analytics before the visitor accepts?

Under EU law, no, not if the analytics tool falls outside the narrow exemption list, and most do. The safer approach is to hold every analytics tag until consent is granted, which is what Google Consent Mode's basic mode does by default. Advanced mode loads tags immediately and sends reduced "cookieless" signals before consent, but whether that counts as access to device storage under Article 5(3) is disputed among regulators, so treat it as the less defensible option rather than a workaround. The UK is a partial exception: from early 2026, first-party aggregate analytics can run without consent under PECR, provided visitors are informed and given an opt-out.

What is the difference between GDPR and the ePrivacy Directive for cookies?

The ePrivacy Directive (Article 5(3)) is the law that actually requires consent before storing or reading anything on a visitor's device that isn't strictly necessary, cookies, pixels, localStorage, all of it. GDPR doesn't create that requirement; it defines what a valid "yes" has to look like (freely given, specific, informed, an affirmative action) and adds transparency duties about how the resulting data gets used afterward. In short: ePrivacy decides whether you need to ask, GDPR decides whether your asking was done right.