Skip to main content
C
CookieBeam
Back to Guides
Compliance5 min read

Pre-Ticked Boxes and Other Invalid Cookie Consent

Pre-ticked boxes, "by using this site you agree," and scroll-to-consent all look like consent and none of them are. Here's what makes cookie consent legally invalid, with the case law behind each one.

Consent has a legal definition, and most banners miss it

Under the GDPR, consent must be a "freely given, specific, informed and unambiguous" indication of the person's wishes, given through "a clear affirmative action" (Article 4(11)). Recital 32 removes any doubt about the edges: "silence, pre-ticked boxes or inactivity should not therefore constitute consent." A lot of consent mechanisms that look normal fail that test. Here are the ones regulators keep striking down.

Pre-ticked boxes: the Planet49 ruling

In October 2019 the Court of Justice of the EU decided Planet49 (Case C-673/17). Planet49 ran an online lottery with a consent checkbox for advertising cookies that was already ticked; users had to un-tick it to refuse. The Court held that this is not valid consent. Consent requires active behaviour, and it's impossible to tell whether a user who left a pre-ticked box alone actually agreed or simply didn't notice it. The ruling applied whether or not the stored data was personal, because the ePrivacy consent requirement covers the act of storing information on a device. A pre-selected "on" toggle for non-essential cookies has been indefensible ever since.

Continued browsing and scroll-to-consent

"By continuing to browse, you accept cookies" is not consent. Neither is scrolling down the page. The EDPB's Guidelines 05/2020 state plainly that scrolling or swiping through content does not satisfy the requirement for a clear affirmative action, because it can't be distinguished from ordinary use of the site. The CNIL and Italy's Garante both moved to ban continued-browsing consent in their national cookie guidelines. If a visitor can trigger "consent" without doing anything they'd recognise as agreeing, it isn't consent.

Bundled consent

Consent has to be specific. Rolling cookie consent into your terms and conditions, or asking for one blanket "yes" that covers analytics, advertising, and personalisation together, fails on two counts: it isn't specific to each purpose, and it usually isn't freely given (the user can't accept the service without also accepting the tracking). Non-essential purposes need separate, granular choices: a visitor has to be able to say yes to analytics and no to advertising, and have both stick.

Setting cookies before the click

The word in the law is prior. Consent has to come before the cookie is placed, not after. A banner that fires your analytics and advertising tags on page load, then shows an "accept" button, has already broken the rule by the time the visitor reads it. This is one of the most common findings in banner audits, and it's why blocking scripts until consent matters more than the banner's wording. See why most cookie banners fail.

Consent with no real choice

If refusing costs the user access (a hard cookie wall) or is buried behind extra clicks while accepting takes one, the choice isn't free. That covers both "pay or consent" walls, whose legality is contested and jurisdiction-dependent (see the cookie wall guide), and the asymmetric "Accept All" banners that the one-click reject rule targets.

Uninformed consent

Consent isn't informed if the visitor can't see what they're agreeing to. That means naming the purposes, and for third-party tracking, being able to identify who's involved. A banner that says "we use cookies to improve your experience" and nothing else hasn't informed anyone. Vague purpose language is a documented enforcement trigger, including in the CNIL's fine against Yahoo.

How regulators actually test a banner

When an authority reviews a consent mechanism, they don't read your privacy policy first. They load the page in a fresh browser and watch what happens. Do cookies get set before any click? Is there a way to refuse that's as easy as accepting? Is anything pre-ticked? Can they identify the purposes and the third parties? Each invalid form above fails one of those live checks, which is why wording alone never rescues a banner that behaves badly on load. The behaviour is the evidence.

Silence is not a yes

One theme connects every invalid method here: they all try to manufacture consent out of a user doing nothing. Recital 32 of the GDPR was written to close that door, listing "silence, pre-ticked boxes or inactivity" as things that don't count. Whenever a design lets you record a "yes" without the visitor taking a deliberate, informed action they'd recognise as agreement, it's on the wrong side of that line. That's the single test to apply to any consent pattern you're unsure about.

Ambiguous or hidden consent

Consent also fails when it's unclear what the click meant. A single "OK" or "Got it" button, with no visible reject and no purpose breakdown, is ambiguous: the user acknowledged the banner but didn't necessarily agree to tracking. Regulators read ambiguity against the site, not the user. If the only available action dismisses the banner, you've recorded a dismissal, not consent.

What valid consent looks like

Put positively, consent that holds up is: opt-in (nothing pre-selected), granular (a choice per purpose), informed (clear purposes and vendors), free (reject as easy as accept, no dark patterns), and reversible (withdrawal as easy as giving). And you have to be able to prove it after the fact, which means logging each decision. A consent platform like CookieBeam enforces opt-in by blocking non-essential cookies until the visitor chooses, keeps the choices granular, and timestamps each one. For the record-keeping side, see proof of consent documentation.

Sources

Back to all guides
Pre-Ticked Boxes & Invalid Cookie Consent | CookieBeam | CookieBeam