What "reject all" really has to do under GDPR (and why most banners get it wrong)

Banner parity is among the most-enforced consent rules in the EU. On 31 December 2021 CNIL fined Google €150 million (délibération SAN-2021-023, split €90M against Google LLC and €60M against Google Ireland) and Facebook Ireland €60 million (SAN-2021-024). In both cases the finding was the same: refusing cookies took more work than accepting them. Italy’s Garante, the Spanish AEPD, the German Land data protection authorities and the Belgian APD have taken the same line. The rule is not interpretive, it has specific, enforced requirements.

The rule, plainly

From CNIL’s guidelines on cookies and other trackers (délibération 2020-091, adopted 17 September 2020, enforced from the end of the grace period on 31 March 2021):

It must be as easy to refuse to consent as to give consent... If the user can consent at the first level by clicking on a single button, refusing must also be possible at the first level by clicking on a single button.

The EU-wide instrument for banners is not the EDPB’s Guidelines 03/2022 on deceptive design patterns, which are scoped to social media platform interfaces and are routinely miscited on this subject. It is the report of the EDPB’s Cookie Banner Taskforce, adopted 17 January 2023, which records the positions a large majority of national authorities found common ground on. That report is deliberately modest about its own reach: it describes itself as a common denominator and a minimum threshold, and says it does not prejudge any national authority’s own analysis. The part that is settled: a design that makes accepting easier than refusing invalidates the consent.

What passes parity

• Two buttons, equal prominence. “Accept all” and “Reject all” on the same banner, same row, similar size, equivalent color treatment (either both branded or both neutral).
• Three buttons. “Accept all,” “Reject all,” “Manage preferences.” Each on the first banner. Slightly bigger panel footprint, but parity-clean.
• Toggles defaulted to off, plus accept-all + reject-all buttons. The toggle UI is the granular path; the two buttons are the one-click paths. As long as both one-clicks are present on the first surface, this passes.

What fails parity

• “Accept all” button, “Manage preferences” link. The CMP industry’s most common default. Reject requires the user to click into a second panel and click reject there. Per CNIL: invalid consent. Fines have followed.
• Refusal present only as inline body text. The banner says somewhere in its paragraph that you may decline, but nothing on the surface is styled as a refusal control, so a user scanning the banner sees one option. Worth separating from a myth that circulates widely: a clearly placed “Continue without accepting” link is not the defect. CNIL’s recommendation 2020-092 uses that exact label in its own examples of compliant banners, and CNIL’s own site carries it. If you have that control, do not remove it on the strength of a blog post, this one included.
• “Accept all” in brand colour, “Reject all” as grey link text. Handle this claim carefully, because it is where most published advice overreaches. The Cookie Banner Taskforce expressly refused to impose a general colour or contrast standard (paragraph 17); the only contrast it condemns outright is text you cannot read against its background (paragraph 18). What authorities do act on is the point where reject stops looking like a control at all and starts looking like fine print, so that finding it takes effort accepting does not. Italy states a visual-equivalence requirement explicitly; elsewhere it is judged case by case.
• Reject requires more clicks than accept. If accept is one click and reject is one click followed by a confirmation modal, accept is easier. Invalid.
• Reject button greyed out until the user reads the policy. The UX trick of making the reject path require interaction (scrolling, reading) to activate. This is the core defect in plain form: refusing costs effort that accepting does not.
• Pre-ticked checkboxes for categories. Already established by the Planet49 CJEU decision (C-673/17, October 2019): consent must be active. Pre-ticked is invalid.
• Banner that re-appears on every page until accept. Pressure to accept. Invalid.

The CNIL-Google decision in detail

CNIL’s €150M fine of Google (délibération SAN-2021-023, 31 December 2021, €90M against Google LLC and €60M against Google Ireland) named the specific defect: google.fr and youtube.com offered a single button that accepted cookies immediately, while refusing required, in the decision’s own words, « au moins cinq actions » — at least five actions.

• Accept-all: 1 click on a clearly labelled button.
• Reject path: at least five actions, spread across more than one screen, before the refusal was recorded.

CNIL held that this asymmetry discouraged refusal and invalidated the consent. Note how large the real gap is, because the figure is frequently repeated as three clicks: the decision found five actions or more. The fine reflected both the breach and the scale of Google’s French traffic.

The Italian Garante position

The Garante’s 2021 guidelines (Provvedimento 231 of 10 June 2021) added a specific design requirement: equivalent visibility. Two buttons that are present but differently styled, accept in green, reject in gray, fail Garante’s visibility test even when click count is equal.

The CMP configuration problem

Parity failures are usually configuration, not product. Nearly every consent platform on the market can render a first-layer reject button; whether yours does depends on the template you picked and the toggles you left alone. The two shapes we see most:

• The configured template buries reject behind a “Manage” link.
• The configured template puts accept and reject on the same surface, but the styling makes accept a prominent button and reject a quiet link.

We are not going to publish a list of vendors and their defaults. Templates change between product versions, between resellers, and between the plan tiers of the same vendor, so any such list is stale on arrival and unfair to whoever is on the version that fixed it. The noyb complaint waves of 2022 are sometimes cited as proof that particular products ship broken; they were aimed at how the sites in question had configured them. The only statement worth making is about your banner, as it renders today.

The fix is almost always a setting: turn on “show reject button on the first layer,” then give the two buttons the same treatment.

The cost of failure

Fines for banner parity violations have ranged from €5k (small SMB, German DPA) to €150M (Google). CNIL has stated that small businesses face proportional fines, not headline-grabbing ones, but the regulatory cost is not the largest exposure, the larger cost is that invalid consent invalidates all the data collected under it. A 12-month archive of analytics gathered under a non-compliant banner is data that cannot be lawfully retained.

Veracly’s parity check, and what it deliberately does not do

The parity check is a static inspection of the banner DOM, not a behavioural test. On each page we scan, we capture the banner element, enumerate the buttons inside it, classify each as accept, reject or manage, record whether it is visible, hidden, or positioned off-screen, and compute a visual weight for each one. Visual weight is rendered area multiplied by font weight, expressed as a fraction of the heaviest visible button. If the strongest reject button falls below 0.7 of the strongest accept button, or if reject exists only behind a submenu or off-screen while accept sits on the main banner, we raise reject-not-equal-to-accept and cite CNIL 2020-091 and the EDPB Cookie Banner Taskforce report.

Four limits, stated plainly, because they change how you should read the result:

• We do not measure colour contrast or click distance. Area and font weight are what we compute. Any judgement about colour is yours, and given what the Taskforce actually said about colour standards, that is the right division of labour.
• We never click your banner. A click would itself be a consent gesture and would pollute the pre-consent reading, which is the more valuable measurement and the one regulators ask about first. So we do not verify that pressing Reject stops the tags. We inspect whether the choice is presented fairly, and you test the behaviour yourself.
• When we cannot enumerate the buttons, we grade nothing. Banners that keep their controls in a closed shadow root, or render them outside the banner root, return an empty button list. In that case the parity verdict is withheld for that page rather than guessed. “No reject enumerated” is not the same observation as “no reject exists,” and we have shipped that exact false positive once already.
• A free scan covers one page. Banners are usually site-wide, so one page is usually enough to judge the banner, but if yours varies by section you are seeing one section. Paid scans crawl to the page cap of the plan.

The report cites the specific CNIL and EDPB guidance behind each finding and the configuration change that typically resolves it.

See also: Cookie banner audit checklist · GDPR vs ePrivacy: which one governs cookies?