Component · Cookie consent
A banner that produces a record you could defend.
Most cookie banners collect a click. This one collects a consent record — the exact wording shown, the version of it, the categories chosen and the moment. Without that, withdrawal is unprovable and the banner was decoration.
The banner, as the template ships it
Before you carry on
Notice v4 · first layerWe use cookies for four different things, and only the first is required to run the site. Nothing optional is running while you read this.
Template controls
Placement
Accent
Corners
Reject button
The default, and the only one that is safe everywhere. Reject is as reachable as accept.
The record it writes
- Subject
- Not yet decided
- Wording shown
- Notice v4, as published 22 Jun 2025
- Granularity
- First layer
- Allowed
- —
- Method
- —
- Recorded
- —
- Withdrawable
- One click, from the footer, permanently
- Re-ask
- Only when the wording version changes
Written the moment a choice is made. A click with no record behind it is not consent, it is a dismissed dialog.
Why the template refuses things
Six patterns this component will not let you ship
Each one is common, and each one makes the consent invalid rather than merely aggressive. A banner that produces invalid consent is worse than no banner, because it creates a record that says you asked.
No pre-ticked optional boxes
Everything except strictly necessary starts off. A box you did not untick is not a choice you made.
No tags before the choice
Nothing optional loads while the banner is on screen. Asking afterwards makes the banner a formality.
No reject buried behind “manage”
Reject all sits on the first layer, one click, beside accept. This is the pattern regulators cite most often.
No cookie wall on essential services
Refusing cannot lock a customer out of their own account. Consent given to avoid losing access is not freely given.
Withdrawal as easy as consent
A permanent link in the footer, not an email to support. If it takes more effort to leave than to enter, the consent has failed.
Re-ask only on a version change
The record stores which wording was shown. Change the wording materially and the old agreement does not carry over.
When it is wired to the application
The banner is the easy half
Anyone can render a bar. What decides whether the consent survives a regulator reading it is what happens to the record afterwards — and that is the half most implementations skip.
- 01
The record goes to the consent register
Not to a local storage key that clears when somebody empties their browser. A withdrawal you cannot evidence is a withdrawal that did not happen.
- 02
Categories map to real processors
Each toggle names the recipients it releases. Marketing off means those four recipients stop receiving, everywhere — not just on this page.
- 03
Withdrawal propagates to the audiences
The most common failure in the whole product area: consent withdrawn in one system, audience unchanged in another. That is what produced the complaint on ACT-030.
- 04
The wording version is pinned
Publishing v5 does not silently re-authorise anybody who agreed to v4. Asiri can tell you how many people are in that position before you publish.
- 05
Every change lands on the audit trail
Who changed the banner wording, when, and why — the same as any other record. A consent notice edited quietly is the thing nobody can defend later.