Category: Consent Interfaces

Reject All Button

Also known as: I Reject Button, I Decline Button, Decline All Button

Simply put

A 'Reject All' button is a control on a cookie consent banner that lets a website visitor decline non-essential cookies and similar tracking technologies with a single action, rather than having to turn off options individually. It is intended to make refusing tracking as straightforward as accepting it. Whether such a button is legally required, and where it must appear on the banner, depends on the jurisdiction and on how the banner is designed.

Formal definition

The 'Reject All' button is a consent-interface element that, when selected, signals a user's refusal of consent for non-essential or non-strictly-necessary cookies and equivalent technologies (such as pixels, local storage, SDKs, or fingerprinting), typically allowing only strictly necessary technologies to operate. In several EU and UK regulatory positions, the presence and prominence of a reject mechanism is treated as relevant to whether consent is freely given and unambiguous, since refusal should generally be as easy as acceptance; some guidance indicates that a first-layer 'Reject All' may not be strictly required where no accept button is displayed on that layer or where the user can otherwise interact without consenting. However, the exact requirements, whether the button must appear on the first layer, and how it must be presented, are not uniform across jurisdictions, remain subject to evolving data protection authority guidance, and differ under opt-out-oriented frameworks such as US state privacy laws. This entry does not resolve those contested points or assess the compliance of any specific banner design.

Why it matters

The presence and prominence of a 'Reject All' button sits at the heart of a broader compliance principle in EU and UK law: for consent to be considered freely given and unambiguous, declining tracking should generally be as easy as accepting it. Where a banner offers a prominent single-click 'Accept All' but forces users through additional steps or layers to refuse, several data protection authorities have treated that imbalance as a factor weighing against valid consent. This makes the button a frequent focal point in discussions of banner design and enforcement scrutiny.

The requirement is not uniform, however, and the details matter. Regulatory guidance from the UK and EU indicates that a first-layer 'Reject All' may not be strictly required in every configuration, for example, where no accept button is displayed on that layer, or where the user can otherwise interact with the site without consenting. Because of this nuance, treating a first-layer 'Reject All' as a universal legal mandate would overstate the position; likewise, its absence is not automatically unlawful in all circumstances.

Under opt-out-oriented frameworks such as US state privacy laws, the analysis differs again, since those regimes generally rely on opt-out mechanisms rather than the prior opt-in consent model that shapes EU and UK banner design. Organizations operating across multiple jurisdictions therefore cannot assume that a single banner design satisfies every applicable regime, and should treat the 'Reject All' button as one design element among several that supports, but does not by itself guarantee, compliance.

Who it's relevant to

Privacy and data protection officers

DPOs and privacy teams responsible for cookie consent in the EU and UK need to understand how the presence, wording, and placement of a reject control bear on whether consent is freely given and unambiguous. They should track evolving data protection authority guidance rather than assuming a fixed rule applies everywhere.

Legal and compliance counsel

Counsel advising on banner design must weigh the contested and non-uniform requirements around reject buttons across jurisdictions, including situations where a first-layer 'Reject All' may not be strictly required. They should distinguish EU and UK opt-in expectations from opt-out-oriented US state privacy frameworks.

Web developers and CMP implementers

Those building or configuring consent banners and consent management platforms translate legal requirements into interface elements. They implement the technical behavior that suppresses non-essential cookies, pixels, SDKs, and similar technologies on refusal, and ensure the choice is logged for record-keeping.

Marketing and analytics compliance teams

Teams relying on analytics, advertising, and functional technologies need to know that a reject signal generally halts non-essential tracking, affecting data collection. They should coordinate with legal and privacy functions rather than treating any banner configuration as guaranteed to be compliant.

Inside Reject All Button

Reject All Control

A single interactive element that allows a user to decline all non-essential cookies and similar technologies (such as analytics and advertising cookies, pixels, SDKs, and local storage) in one action, mirroring the ability to accept all in one action.

Parity with Accept All

The principle, emphasized by several EU data protection authorities, that rejecting non-essential technologies should be as easy as accepting them, typically meaning the reject option is presented at the same layer and with comparable prominence to the accept option.

Scope of the Rejection

The reject action generally applies to consent-requiring cookies and technologies. Strictly necessary or essential cookies are generally exempt from consent under EU law and may continue to operate, so a reject all button does not typically disable those.

Placement within the Consent Interface

Where the button appears in the first-layer banner or consent management platform (CMP) dialog, including its visual weight, colour, and position relative to the accept and settings controls.

Link to Consent Logging

The rejection outcome is generally recorded as part of consent or preference record-keeping so the user's choice can be evidenced and respected on subsequent interactions, though the record-keeping mechanism is a separate CMP function.

Common questions

Answers to the questions practitioners most commonly ask about Reject All Button.

Does having a 'Reject All' button by itself guarantee that my cookie banner is compliant?

No. A 'Reject All' button is one element that data protection authorities in several EU jurisdictions have indicated supports valid consent, but its presence alone does not guarantee compliance. Compliance depends on the banner as a whole, including whether consent is freely given, specific, informed, and unambiguous, whether non-essential cookies are actually blocked before consent, how choices are logged, and how the overall design avoids nudging users toward acceptance. A button is a tool that supports compliance; it does not replace an assessment of the full consent flow against the applicable legal requirements, which vary by jurisdiction.

Is a 'Reject All' button legally mandatory everywhere?

Not universally. Guidance from some EU data protection authorities has taken the position that rejecting should be as easy as accepting, which in practice often points toward offering a reject option at the same level as accept. However, requirements differ between the EU, the UK, and individual US states, and the exact form is not identical across all regimes. Many US state frameworks rely on opt-out mechanisms rather than an opt-in reject button, so the concept does not map directly. You should confirm the specific obligations for each jurisdiction in which you operate, as enforcement positions and authority guidance continue to evolve.

Where should the 'Reject All' button be placed relative to the 'Accept All' button?

A common approach informed by the principle that rejecting should be as easy as accepting is to present both options at the same layer of the banner, with comparable visual prominence, size, and effort required. Placing 'Reject All' behind additional clicks or in a secondary settings screen while 'Accept All' is immediately available may be viewed critically by some EU authorities as a form of nudging. The appropriate placement can depend on the applicable jurisdiction and the authority guidance in force, so treat equal accessibility as a general design goal rather than a fixed rule that applies identically everywhere.

What should actually happen technically when a user clicks 'Reject All'?

In most EU implementations, clicking 'Reject All' should mean that non-essential cookies and similar technologies, such as analytics and advertising cookies, tracking pixels, SDKs, and non-essential local storage, are not set or accessed. Strictly necessary or essential cookies generally remain, since they are typically exempt from consent under the ePrivacy rules. The rejection choice should also be recorded so it can be respected on subsequent visits. Note that any personal data already processed may still be subject to GDPR obligations, and the exact technical behaviour should be verified against how your tag management and consent tooling are configured.

Should a 'Reject All' choice be logged, and if so, what should the record contain?

Recording consent decisions, including rejections, is generally advisable to help demonstrate accountability where that is required, and consent management platforms typically capture these events. A record commonly includes the choice made, a timestamp, and information about the banner version or configuration presented. The specifics of what must be retained, and for how long, depend on the applicable legal regime and your own accountability needs, so this should be aligned with your broader record-keeping approach rather than assumed to be identical across jurisdictions. A CMP can support this logging but does not by itself determine what your legal retention obligations are.

How should a 'Reject All' button interact with a consent management platform or the IAB TCF?

Where a CMP or a framework such as the IAB Transparency and Consent Framework is used, the 'Reject All' action should propagate the user's decision through the relevant signals and configurations so that downstream tags and vendors do not process data on the basis of consent that was not given. The button is part of the user-facing layer, while the CMP and framework handle how that decision is communicated technically. Configuring these correctly is a technical and organizational task, and the fact that a CMP or framework is in use does not on its own establish that the resulting flow meets the legal standards applicable in a given jurisdiction.

Common misconceptions

A reject all button is legally mandatory everywhere.

The expectation of an easily accessible reject option stems primarily from EU (and UK) guidance interpreting the requirement that consent be freely given, informed, and given by clear affirmative action. Requirements differ by jurisdiction: US state privacy laws such as the CCPA and CPRA in California generally rely on opt-out mechanisms rather than opt-in consent banners, so the design expectations there differ. The scope of any claim depends on the applicable legal regime.

Including a reject all button makes a consent banner compliant.

A reject option addresses one aspect often flagged by regulators, parity between accepting and rejecting, but it does not by itself make a banner compliant. Compliance also depends on factors such as adequate information, absence of pre-ticked boxes or deceptive design, prior consent before non-essential technologies fire, and proper record-keeping. A CMP feature supports compliance but does not replace legal judgment.

Rejecting all cookies stops every cookie and technology on the site.

A reject all action generally applies only to consent-requiring technologies. Strictly necessary or essential cookies are typically exempt from consent under EU law and may continue to operate even after a user rejects. The precise categorisation of a given cookie depends on facts not covered by this definition.

Best practices

Present a reject option at the same layer and with comparable prominence to the accept option, in line with guidance from several EU data protection authorities that rejecting should be as easy as accepting.

Ensure non-essential cookies and equivalent technologies (pixels, SDKs, local storage, fingerprinting) do not fire before the user makes a choice, so that a rejection is honoured before any consent-requiring processing begins.

Log the rejection as part of your consent or preference records so the choice can be evidenced and respected on return visits, recognising that record-keeping is a distinct CMP function.

Avoid deceptive design patterns such as visually de-emphasising the reject control or hiding it behind additional clicks, which regulators in the EU and UK have criticised.

Tailor the interface to the applicable legal regime, an opt-in reject/accept model for EU and UK visitors versus opt-out mechanisms typically expected under US state laws such as the CCPA and CPRA, rather than assuming one design fits all jurisdictions.

Treat the reject all button as one component of a broader compliance approach and confirm the overall banner and CMP configuration with qualified legal advice, since tools support but do not guarantee compliance.