Consent lifetime and withdrawal

Two questions every consent banner has to answer, and both are settings under Settings → General rather than anything you need to code.

How long consent lasts

Consent expiration is how many days a visitor's choice stays valid. After that the banner asks again, as if they had never answered.

The default is 365 days. The maximum is 390 — thirteen months — which is the IAB TCF limit and also the ceiling the French CNIL recommends for everyone else, so a longer value would be invalid on a TCF site and hard to defend on any other.

One setting covers both banners: it is the lifetime of the visitor's cw_consent cookie on a category banner, and of the TC string on a TCF one.

Changing it moves the goalposts for people who already decided

Shortening it re-prompts visitors sooner than they expect. Lengthening it does the opposite, and a visitor who consented under the old value keeps their existing expiry until they answer again — the new number applies from their next decision, not retroactively.

If you need to re-ask everyone immediately — you added a vendor, changed what a category does, rewrote the copy — use Renew consents instead. That is what it is for, and it does not touch the expiry.

Where consent applies: one host or the whole domain

Subdomain consent sharing decides how far a decision reaches. It is off by default, and off means a visitor's answer stays on the host they gave it on: a choice made on shop.example.com does not answer for app.example.com, so they see the banner again there.

Turn it on and the consent cookie is written to your root domain instead, so every subdomain — and the root itself — reads the same decision.

Nothing else changes: the same cookie name, the same lifetime, the same categories. Only where the browser is willing to send it.

It applies from the next decision, not retroactively

Visitors who already answered keep the cookie they have, on the host that wrote it, until it expires or they answer again. So a site that turns sharing on sees it take effect gradually rather than all at once. If you want everyone on the new scope immediately, Renew consents is the way to ask them all again.

One site per root domain

If you run two separate CookieWave sites under one root domain — say a marketing site on example.com and a product on app.example.com, each with its own banner — do not turn sharing on for both. A cookie sent to a root domain reaches every host under it, and there is no way to write "this applies to these subdomains only": the browser's Domain attribute takes one domain and covers everything beneath it. Both sites would be writing the same cookie name to the same place, and each would discard the record belonging to the other, so their visitors would keep being re-asked. Turn it on for at most one of them.

Adding a subdomain under Settings → General → Subdomains is a separate thing: that is which hosts your banner is allowed to run on. Sharing is whether they answer for each other.

Anything under your root domain can be added there, not only hosts under the domain you entered as primary: a site whose primary domain is www.example.com can add shop.example.com and example.com too. What it cannot add is a domain belonging to somebody else — the check works out your root domain properly, so on a site at shop.example.co.uk the root is example.co.uk and bbc.co.uk is refused, rather than both counting as co.uk. localhost is allowed regardless, so you can run the banner on your own machine.

What happens when a visitor takes something back

Withdrawal is not just "stop doing it from now on". Under GDPR Art. 7(3) it has to be as easy as consenting, and data stored under a consent that has been withdrawn has nothing left to justify it. So when a visitor turns a category off, CookieWave deletes the cookies that category had set.

Which cookies those are comes from your site's own scan: the list you see under Manage cookies, per category. Three consequences worth knowing:

• A category with an empty list clears nothing. If you added a tag after your last scan, run a new scan — otherwise withdrawal leaves its cookies in place.
• Cookies on other domains cannot be deleted. No JavaScript can delete a cookie set on doubleclick.net from your site. That is a browser rule, not a limitation of the banner, and it is the reason blocking a tag before consent matters more than cleaning up after it.
• The consent record itself is never deleted. cw_consent, and euconsent-v2 / addtl_consent on TCF sites, survive a withdrawal. Erasing them would destroy the evidence of the decision the visitor just made, and the banner would come back as though they had said nothing.

Reload after withdrawal

Off by default. When on, the page reloads after a visitor takes a permission back.

It only acts in that direction, which is the whole point of it:

Visitor accepts	No reload. The banner activates the scripts it was holding back, so a reload would only lose whatever they had typed into your forms.
Visitor withdraws	Reload, if you turn this on. A script that has already run cannot be unloaded — stopping it needs a fresh page.

Turn it on if third-party code on your site keeps working after its cookies are gone: a chat widget that has already opened a socket, an analytics library that read consent once at startup, anything that decided what to do before the visitor changed their mind.

Leave it off if your page holds state a reload would throw away — a checkout step, a long form, a media player. Consent Mode signals and the script blocker both take effect without it.