GDPR Cookie Consent Requirements

What GDPR and ePrivacy require for cookies#

Cookie rules in Europe come from two laws working together. The ePrivacy Directive, an EU law from 2002 that governs privacy in electronic communications, contains the rule most people mean when they say cookie law. Its Article 5(3) says a website may store information on a user's device, or read information already stored there, only after the user has given consent, with a narrow exception for what is strictly necessary. The GDPR, the General Data Protection Regulation, then defines what counts as valid consent and sets the standard that consent has to meet.

It helps to be clear about where the law stands today, because the framework has been unsettled. For years a replacement called the ePrivacy Regulation was under discussion, but the European Commission withdrew that proposal on 5 February 2025, a decision recorded in the EU Official Journal on 6 October 2025, so the 2002 Directive remains the governing law with no successor in force. In November 2025 the Commission's Digital Omnibus package proposed moving the cookie rules into the GDPR itself through new Articles 88a and 88b, though that proposal is still under negotiation and has not been adopted. What this means in practice has not changed, since consent before non-essential cookies is the rule now and stays the rule.

The strictly necessary exception is deliberately narrow. A cookie is strictly necessary when the service the user explicitly asked for cannot work without it. Keeping a user logged in during a session, remembering items in a shopping cart, spreading traffic across servers for load balancing, and protecting a login form all qualify. These need no consent because the visitor cannot get the service they came for without them.

Everything else needs consent before it runs. Analytics cookies that measure how people use the site, advertising cookies that build a profile for targeting, and third-party cookies dropped by embedded widgets are all non-essential cookies, meaning they are not required to deliver the service the visitor asked for. Convenient for the site is not the same as necessary for the user, and only genuine necessity earns the exemption.

Cookie type	Consent needed?	Typical examples
Strictly necessary	No, exempt	Login and session, shopping cart, load balancing, login security
Functional and preferences	Yes	Remembered language, theme, saved settings
Analytics and performance	Yes	Google Analytics (_ga), usage measurement, heatmaps
Advertising and marketing	Yes	Google Ads (_gcl_au), retargeting pixels, social widgets

One more piece of vocabulary matters here. The organization running the site is the controller, the party that decides why and how personal data is collected, and the controller carries the legal duty to get consent right. Saying the cookies came from a third-party plugin is not a defense, because the responsibility sits with the site, not the tool.

What counts as valid consent#

Getting a banner on the screen is easy. Getting consent that actually counts is the hard part, and GDPR is specific about it. Article 4(11) defines consent, and Article 7 sets the conditions it has to satisfy. Four requirements sit at the center, and a banner has to honor all of them.

Consent must be freely given. The user needs a real choice with no penalty for saying no. If refusing leaves the site unusable, or the banner nags relentlessly until the user gives in, the choice was not free.

Consent must be specific. A single yes cannot silently cover analytics, advertising, and personalization all at once. The user consents to each purpose on its own terms rather than to a bundle.

Consent must be informed. Before deciding, the user needs to know who is collecting the data, what it will be used for, and how to change their mind later, written in plain language rather than dense legal text.

Consent must be unambiguous, given by a clear affirmative action. The user has to do something active, such as clicking Accept. Silence, a pre-ticked box, or continued browsing does not count.

The four conditions of valid consent

All four must hold, or the consent is not valid (GDPR Art 4(11)).

That last requirement rules out two patterns still common on the web. Pre-ticked boxes, where a category is switched on and the user has to switch it off, are invalid because the user never took a positive action. Implied consent, the idea that scrolling the page or simply continuing to browse means yes, fails for the same reason. The Court of Justice of the European Union confirmed in its 2019 Planet49 ruling that a pre-ticked box does not produce valid consent.

A newer question tests the freely given standard head on. Some large sites now present a consent or pay choice, where a visitor either agrees to tracking or pays for a version without it. In Opinion 08/2024, published in April 2024, the EDPB, the European Data Protection Board that coordinates the EU's privacy regulators, found that for large online platforms offering only agree or pay generally does not produce valid, freely given consent. It is a case by case assessment, and a compliant version usually needs an equivalent free alternative, for example one funded by contextual advertising, which picks ads from the content of the page rather than from a profile of the visitor.

IAB TCF signals still need real consent

Many advertising tools speak the IAB TCF, the IAB Europe Transparency and Consent Framework, an industry standard for collecting and passing consent signals across the ad ecosystem. Using it does not make a banner compliant on its own. The signal it passes is only as valid as the consent behind it, so the same freely given, specific, informed, and unambiguous test still applies.

What a compliant banner must do#

A compliant banner is not decoration. It is the mechanism that collects valid consent, so its design has to match the standard consent must meet. The most scrutinized detail is button parity, meaning Accept and Reject should be equally easy to find and use, presented with equal prominence. The EDPB's binding guidelines are blunt about it, treating consent as not freely given when the interface steers the visitor toward acceptance. A banner that makes accepting a bright single click while hiding rejection behind extra clicks or a faded link is exactly that kind of nudge. In the Austrian ORF case, a court ruled in October 2024, later confirmed, that a Reject option shown in a less conspicuous colour was not enough, and that Accept and Reject need equal prominence on the first layer of the banner. Reject all should be reachable in as few clicks as Accept all.

Compliant vs dark pattern banner

Regulators treat unequal prominence as a nudge, not a free choice (Austrian ORF and German Hanover rulings).

Regulators across Europe have made the same point through enforcement. Germany's Hanover Administrative Court held on 19 March 2025 that sites must offer a clear reject all button and that manipulative designs are not allowed. France's data protection authority, the CNIL, issued 331 corrective measures in 2024 and sent formal notices in December 2024 aimed squarely at dark pattern banners. The direction of these decisions is consistent, so a banner that quietly favours Accept is a growing legal risk, not a clever optimisation.

Set no non-essential cookies when the page first loads. Nothing beyond strictly necessary cookies should run until the visitor has consented, so analytics and advertising tags stay dormant until then.
Offer granular choice by purpose where practical, letting a visitor accept analytics while refusing advertising instead of facing one switch that covers everything.
Leave every non-essential category switched off by default, with no pre-ticked boxes, so consent comes only from an action the visitor takes.
Make withdrawing consent as easy as giving it, which Article 7(3) requires directly, usually through a persistent link or icon that reopens the choices at any time.
Give clear information before the visitor decides, with a linked cookie policy that lists the cookies in use, their purposes, and any third-party recipients.

A well built banner ties these together. The visitor sees a short, plain explanation, two balanced buttons, and a way to choose by purpose, and behind the scenes nothing non-essential fires until they make a positive choice. Everything after that, from analytics to ad targeting, follows the decision they actually made rather than a decision the design nudged them into.

A nudged choice can void the consent

A design that steers the user toward Accept, such as a bright Accept button beside a faint Reject link, is treated as a dark pattern that undermines the freely given requirement. When regulators find one, they can rule that no valid consent was collected at all, which leaves every non-essential cookie on the site running with no legal basis behind it.

Why cookies before consent break the rules#

The rule that trips up the most sites is also the simplest. Article 5(3) requires consent before storage or access, which means before the cookie is set, not after. Yet a large share of sites load their analytics and advertising tags the instant the page renders, dropping cookies while the banner is still asking for permission. By the time the visitor clicks anything, the tracking has already happened. This is the single most common and most cited cookie violation in enforcement decisions, and it fails no matter how polished the banner looks, because the timing is wrong.

The fix is to hold every non-essential tag until consent exists, then load it. On the tooling side, Google's Consent Mode v2, a mechanism that adjusts how Google tags behave according to the consent a user has given, is built for this. It lets the tags load in a state where storage is denied by default, so no analytics or advertising cookies are written, and it switches storage to granted only once the user accepts. Consent Mode does not replace a banner or excuse a missing one. It is the plumbing that makes the banner's decision actually govern what the tags do.

Getting this order right is what separates a banner that looks compliant from one that is. A banner that looks perfect in a screenshot means nothing if the network tab shows tracking cookies set on load, because the law cares about what runs on the device, not what the interface promises.

Keeping proof of consent#

Collecting consent is only half the duty. Article 7(1) requires the controller to be able to demonstrate that the user consented, which means consent has to be recorded, not just requested. If a regulator or a user asks for evidence, saying that the site shows a banner is not an answer. A stored record is.

A useful consent record captures enough to reconstruct what happened without storing more personal data than needed. At a high level it should note when consent was given with a timestamp, which version of the banner or policy was shown so you can tie the choice to the exact text and options presented, and what the user actually consented to, meaning which categories or purposes they accepted and which they refused. Recording the withdrawal of consent the same way matters too, so the timeline stays complete.

The point is accountability. A dated, versioned record turns consent from a claim into something you can prove, and it protects you when banner wording or the set of cookies in use changes over time. Store it carefully, since a consent log is itself a record about identifiable people and falls under the same data protection rules as anything else you collect.

How to check your banner meets these#

You can check most of this yourself in a few minutes, with no special tooling. Start with the buttons. Open the banner and confirm that rejecting is as quick as accepting, ideally a single click for each, with neither option buried or visually demoted. Then look for a way to withdraw consent later, such as a persistent link that reopens the choices, and confirm it actually works.

The most important check is timing, and browser developer tools make it visible. Before you click anything on the banner, open DevTools and look at what cookies already exist. If analytics or advertising cookies are present before you have consented, the site is setting non-essential cookies too early.

DevTools: check for cookies set before consent

// Run this in the browser console BEFORE clicking Accept on the banner.
console.log(document.cookie);

// What to look for: at this point you should see only strictly
// necessary cookies, such as a session or security cookie.
// If names like _ga (Google Analytics) or advertising cookies
// already appear, the site set non-essential cookies before
// consent, which Article 5(3) does not allow.
//
// Tip: the Application tab, under Cookies, lists every cookie
// by name and origin. Compare that list against your cookie policy.

Reading the cookie list this way tells you exactly where a banner falls short, since it shows what actually ran rather than what the banner claims. Consent decides whether a cookie may exist at all. Making the cookies you do set safe, with attributes like Secure and HttpOnly, is a related job covered in our guide to how to secure cookies, and you can test those attributes with our Cookie Security Checker.

Doing this by hand for one page is quick. Doing it for every page, after every deploy, and every time a marketing tag changes is not. That is where an automated check earns its place. SiteSecurityScore's Cookie Consent & Privacy check visits your site, records which cookies are set before any consent is given, and flags non-essential cookies that fire too early, so a banner that regresses after a tag change shows up as a finding. You can run a scan in seconds, or read the companion walkthrough on how to verify cookie compliance for a fuller checklist.

FAQ#

Is a cookie banner legally required?

A banner itself is not named in the law, but the outcome it produces is required. The ePrivacy Directive requires consent before non-essential cookies are set, and GDPR sets the standard for that consent, so if your site uses analytics, advertising, or other non-essential cookies you need a compliant way to obtain consent first. For most sites a banner or consent notice is the practical way to meet that duty. A site that sets only strictly necessary cookies does not need one.

Does GDPR require a Reject button?

GDPR does not use the word Reject, but it does require that consent be freely given and as easy to refuse as to give. In practice that means a visitor must be able to decline non-essential cookies as easily as they can accept them, so an accessible Reject all option is effectively required. A banner with an easy Accept and no equally easy way to say no does not meet the standard. In the Austrian ORF case, a court ruled in 2024 that a Reject option in a less conspicuous colour was not enough and that Accept and Reject need equal prominence.

Can I set analytics cookies before consent?

No, not before the user consents. Article 5(3) of the ePrivacy Directive requires consent before non-essential cookies are stored or read, and analytics cookies are non-essential because the service the user asked for works without them. Setting them on page load, before the visitor has made a choice, is the most common cookie violation. Hold the analytics tags until consent is given, using a tool such as Google Consent Mode v2 to keep storage denied by default.

Are essential cookies exempt from consent?

Cookies that are strictly necessary to deliver the service the user asked for are exempt from consent under Article 5(3). That covers cookies for keeping a user logged in, remembering a shopping cart, load balancing, and security. The exemption is narrow, though. A cookie is exempt only if the service genuinely cannot work without it, so analytics and advertising cookies never qualify no matter how useful they are to the site.

How long is cookie consent valid before I must ask again?

The law sets no fixed expiry, but consent is not permanent. The CNIL in France recommends, as a best practice, refreshing consent roughly every six months, assessed case by case, and sites in practice commonly ask again somewhere between six and thirteen months, or sooner if the cookies in use or their purposes change materially. You should also ask again whenever you add a new purpose the earlier consent did not cover, since consent has to be specific to what you actually do.

GDPR Cookie Consent Requirements: What a Compliant Banner Must Do