Home / Guides / Reject All Button Requirements Under GDPR

Cookie Banners

Reject All Button Requirements Under GDPR

EU regulators expect a genuine Reject all option as easy as Accept all. Learn layout, behavior, and technical requirements that make rejection real.

Author

GDPRChecker Editorial Team

Reviewed by

Privacy & Compliance Research Team

Last updated

July 2026

Reading time

4 min read

Educational guidance for compliance readiness — not legal advice. Requirements vary by jurisdiction and your specific processing activities.

Introduction

A Reject all button is not a nice-to-have accessibility extra—it is a core requirement for valid consent on most EU-facing sites. Authorities treat rejection as the baseline privacy-preserving choice users must reach as easily as acceptance.

Reject all means one action on the first layer (or an equally prominent parallel path) that denies non-essential cookies, keeps strictly necessary functionality, updates Consent Mode to denied, and prevents analytics and marketing tags from firing on that visit and subsequent pages until the user changes preferences.

Sites that hide Reject in settings, style it as a link, or show Reject that only closes the banner without changing defaults fail both UX ethics and enforcement tests. This guide explains what real rejection looks like.

What it means

Equal prominence requires comparable size, color contrast, and placement for Accept all and Reject all. CNIL's 2020 recommendation and subsequent EDPB cookie banner guidelines explicitly reject interfaces that nudge users toward Accept through visual hierarchy.

One-click rejection on the first layer is the emerging standard. Requiring users to open Manage preferences, scroll past analytics toggles, and hunt for Save without Accept is considered a dark pattern. If you offer granular controls, Reject all still belongs on layer one.

Behavior must match the label. When users click Reject all, set all non-essential categories off, persist that state, call consent update with denied analytics and ad signals, and do not load deferred tags that queued during banner display.

Reject is not the same as Close or X. Closing without a choice should leave defaults denied and tags blocked—not treat silence as consent. Some CMPs incorrectly interpret dismiss as Accept; that is high-risk.

After rejection, users still need access to privacy settings to opt in later. Footer links or icons should reopen the preference center without resetting prior choices silently.

Why it matters

French, Belgian, and Spanish authorities fined major publishers partly for rejection paths that required multiple screens. NGO reports name brands explicitly, creating PR damage beyond administrative fines.

Invalid consent from skewed UI undermines ad data too. Platforms may model conversions, but you cannot defend processing if users never meaningfully opted in.

Reject all is also a product trust signal. Users who want essential content only should get a fast, respectful path without guilt copy such as No thanks, I hate privacy.

Common mistakes

  • Reject buried on second layer only.
  • Reject styled as low-contrast text while Accept is a filled button.
  • Reject sets UI state but leaves GTM consent granted.
  • Reject on homepage only; landing pages auto-accept.
  • Confirm shaming copy adjacent to Reject.
  • Reject clears banner but third-party iframes already loaded trackers.
  • No persisted reject state—every page view shows Accept again without honoring prior Reject.

Practical checklist

  1. Add Reject all button on first layer next to Accept all.
  2. Match button sizing, contrast, and tap targets on mobile.
  3. On Reject, set all non-essential categories denied in storage.
  4. Fire Consent Mode update with denied flags immediately.
  5. Block queued tags and cancel pending network requests where possible.
  6. Test Reject in fresh session across three internal pages.
  7. Document Reject behavior in cookie policy.
  8. Monitor scanner results specifically for post-Reject leaks.

How GDPRChecker helps

GDPRChecker banners include configurable Accept all and Reject all controls on the first layer, designed to meet equal-prominence expectations without custom front-end work.

When users click Reject all, the runtime stores denied categories and keeps tracker blocking active for analytics and marketing scripts defined in your dashboard rules—so rejection is enforced, not cosmetic.

Use the compliance scanner in Reject mode simulation: scan without consent cookies and confirm pre-consent and post-reject phases show blocked Google, Meta, and other configured endpoints.

GDPRChecker tools for cookie consent enforcement

FAQ

Can Reject all live only in settings?
Regulators increasingly say no for EU users. ICO and CNIL expect rejection as easy as acceptance—typically a first-layer Reject all button.
Is a link labeled Continue without accepting cookies enough?
Only if it clearly rejects non-essential cookies and enforcement matches. Vague Continue labels that leave marketing enabled fail scrutiny.
Should Reject all disable necessary cookies?
No. Strictly necessary cookies for security, cart, or login may remain. Reject targets analytics, marketing, and optional functional tools.
Do I need Reject all for UK users?
UK ICO guidance similarly rejects unfair nudging. Provide an equally easy reject path for UK GDPR and PECR alignment.
What if users reject but conversion tracking breaks?
That is expected. Use Consent Mode modeling and focus on consented users rather than overriding rejection silently.

GDPRChecker guides are educational resources and do not constitute legal advice. Use them to understand technical and operational privacy requirements, and consult qualified counsel for legal interpretation.

Check Your Website in Under 60 Seconds

  • No signup required
  • GDPR-focused checks
  • Cookie banner detection
  • Privacy policy verification