The Velo journal

GDPR cookie banner requirements in 2026, and the check that proves each one

Guides·29 July 2026·The Velo team

In 2026 a GDPR compliant cookie banner has to block non essential cookies until someone agrees, offer reject as plainly as accept, split consent by purpose, let people change their mind later, keep a record of what was chosen, and describe all of it in plain language. Most banners state those things. Fewer can prove any of them.

The requirements, and how to prove each one

What follows is the working version: not the legal text, but the shape it takes once you have to build it and show it works. Read each requirement with its check. The checks are missing almost everywhere else, and they are the only reason to trust any of it.

  1. Set nothing non essential before the visitor agrees

    This is the requirement everything else rests on, and the one most often half implemented. A banner that renders while the analytics and advertising tags are already loading has not met it, however the copy is worded. The check: open the site in a clean browser profile, decline everything, then read the cookie jar and the outgoing requests. Only what is genuinely essential should be there.

  2. Give rejecting the same weight as accepting

    Refusal has to be as easy as agreement. In practice that has settled into the same prominence, on the same screen, and the same number of clicks. The check: look only at the first screen and count. If accept is one click and reject takes two, or lives behind a settings link, the banner fails this on its own.

  3. Split the consent by purpose

    One switch for everything is not informed consent. Statistics, marketing and functional purposes are separate decisions and a visitor has to be able to allow one and refuse another. The check: accept statistics only, then watch what fires. If a marketing tag goes out anyway, the categories are decorative and the granularity is not real.

  4. Make changing your mind as easy as making it

    Withdrawal has to be as easy as consent was. In practice that means a persistent control that reopens the choice from anywhere on the site, not a paragraph in the privacy policy explaining how to clear cookies. The check: go to a page deep in the site, find the control, switch from accept to reject, and confirm the tags stop. A banner that reopens and closes again without changing anything is the common failure here.

  5. Keep a record of what was chosen

    Accountability means being able to show what a given visitor agreed to and when, not merely that a banner was installed. The check: ask what your consent record actually contains and whether you can retrieve one, for one visitor, on one date, with the categories they chose. If nobody can answer that, the record does not exist in any useful sense.

  6. Say what you set, in words a person can read

    The banner has to explain in plain language what is being set and why, and the cookie policy behind it has to match reality rather than a template. The check: read the policy against the cookies you observed in the first check. Entries listed but never set are untidy. Cookies set but never listed are the problem.

REQUIREMENT THE CHECK THAT PROVES IT Nothing non essential before consent Decline, then read cookies and requests Reject as plain as accept Count clicks to each, first screen only Consent split by purpose Accept statistics only, watch marketing Withdrawal as easy as consent Reopen from a deep page, change the answer A record of what was chosen Retrieve one visitor, one date, one choice Plain words, matching reality Read the policy against what you just saw
Every item on the left is a claim your banner makes. Only the check on the right can tell you whether it is true on your own site.

Why every checklist stops just before the useful part

Search this question and you get thorough, careful lists. They agree with each other and broadly with the one above. As descriptions of the obligation they are fine, and there is little point writing another one.

What none of them does is tell you how to find out whether your own banner does any of it. Not one gives a browser check, a request to look at, or a way to tell a working install from a decorative one. So the reader finishes the article able to recite the requirements and no better placed to answer the only question they came with, which is whether their site is fine. That is the gap this post is trying to close.

What actually goes wrong, from the installs we see

The failures are rarely a missing requirement. They are requirements that are present in the interface and absent in the code. A banner renders, records the choice, and passes none of it to the tags, usually because a compatibility setting somewhere switched its integrations off. A consent state is written into the page by hand and overrides whatever the visitor picks, so every visitor is recorded as having agreed. Or the denied default is declared a fraction too late, after the first tags have already gone out, which leaves a site that is compliant on the second page view and not the first.

All three look identical from the outside: a correct banner, on a normal page, behaving normally. None of them is visible in a screenshot, which is what most compliance evidence consists of. They show up only on the reject path, which is precisely the path that gets tested least. If you check one thing after reading this, check what your banner sends when somebody declines.

The part that is not really a legal question

Two things get conflated here. Whether you need a banner at all is a question about your visitors and what you set, and we have answered that one separately. What the banner must contain is this article. Neither is legal advice, and the details differ by member state, so a lawyer settles the edge cases, along with what this list leaves out, such as cookie walls and the accessibility of the banner itself.

What is measurable is what the banner costs you. Consent choices hide a meaningful share of sessions from your analytics, measured across Amplio Data client implementations at around 34% of sessions, which is a measured range rather than a guarantee. That is why the second requirement in the list matters commercially as well as legally: a plainly offered reject button tends to produce a more trustworthy accept rate than a buried one, and a correct consent signal recovers part of what a wrong one throws away.

Velo sets the consent state from one snippet before your tags initialise, keeps the record of what each visitor chose, and gives the reopen control the fourth requirement asks for. The mechanism is on the product page.

Common questions

What are the GDPR cookie banner requirements in 2026?

Consent has to be given before any non essential cookie is set, so the banner blocks first and asks second. Rejecting has to be as easy and as visible as accepting, on the same screen. Consent is collected per purpose rather than as one lump, so someone can allow statistics and refuse marketing. Withdrawal has to be as easy as consent was, which in practice means a control that reopens the choice from any page. And you need a record of what was chosen and when. Alongside those sits the transparency duty: plain language, and a cookie policy that matches what your site actually sets.

How do I check my cookie banner is actually GDPR compliant?

Test the reject path, in a clean browser profile, because it is the path nobody tries. Decline everything, then look at the cookie jar and the outgoing requests: nothing non essential should be there. Accept statistics only and confirm the marketing tags stay silent. Then find the control that reopens the banner from a page deep in the site, change your answer, and confirm the state really changes rather than the banner simply closing again. A banner that passes those three has done the part a screenshot cannot show you.

Does a cookie banner have to have a reject button?

The standard applied across the EU is that refusing has to be as straightforward as agreeing. In practice that means a reject control with the same prominence as accept, on the first screen, reachable in the same number of clicks. Burying refusal a layer down under settings is the pattern the rule exists to prevent. We wrote about why one click refusal also tends to be the better commercial choice.

Is implied consent still valid under GDPR?

No. Continuing to browse, scrolling, or a pre ticked box are not consent. Consent has to be an active, informed choice, which is why pre ticked category toggles and banners that set cookies while the visitor is still reading them fail the test regardless of how the wording is phrased.

How long does cookie consent last before I have to ask again?

There is no single number in the GDPR, and guidance differs by member state, so treat any figure you are given as a convention rather than a rule. The common practice is to refresh the choice periodically and to ask again whenever what you set materially changes, for instance when a new vendor or purpose is added. The part that is not optional is that a visitor can change their mind at any point in between.

Stay compliant.
Recover the signal.

Add Velo once and get the banner, the regions, the audit log
and Consent Mode v2 working together, live in minutes.