How long does cookie consent last, and when should the banner ask again
Cookie consent has no expiry written into the GDPR, so it lasts for whatever interval your supervisory authority accepts, commonly set at twelve months. The banner should ask again when that interval elapses, when the vendors or purposes you collect for change, or when no valid consent record can be read. In practice most banners reappear far sooner than the interval anybody configured, for reasons that have nothing to do with the law.
The law sets no clock. The regulators set several.
It is worth being exact, because much published advice states a number as though it were legislation. No article of the GDPR sets a consent lifetime. What the regulation requires is that consent stay an accurate reflection of what the visitor agreed to.
The intervals come from guidance. The European Data Protection Board recommends refreshing consent at appropriate intervals without fixing one, and national supervisory authorities have each turned that into their own figures, which is why published advice disagrees with itself so freely. Commonly cited numbers sit between six and twenty four months, and twelve has become the working default because it lands inside most of that spread. We are deliberately not restating a specific national figure here: the numbers circulating in blog posts routinely conflate different rules, and the only reliable source for the interval that binds you is your own supervisory authority.
The consequence guidance rarely states plainly: whatever number you choose is a maximum, not a promise. It sets how long you may rely on a stored consent, not how long the record survives, and on a good share of your traffic the two are nowhere near each other.
The real reason your banner reappears
Consent is not a legal state persisting somewhere abstract. It is a record: a cookie or a local storage entry sitting in a browser you do not control, whose lifetime that browser decides.
If your consent tool writes that record as a first party cookie from JavaScript, Safari's tracking prevention caps its lifetime at seven days, and at twenty four hours for a visitor who arrived on a link decorated by a known tracker. Configure twelve months and it makes no difference: the record is gone within a week, and every Safari visitor returning after that sees the banner again as though they had never answered. Local storage produces the same outcome by a different route.
A record set by your own server in an HTTP response header escapes that script cap, which is why durable implementations set it that way. One condition applies: if the endpoint is reached through a name pointing at a third party service rather than genuinely being yours, Safari treats it as third party and the cap returns.
None of this is exotic. It is ordinary behaviour across a large share of European mobile traffic, and it is the difference between asking once a year and asking fifty times.
Three reasons a banner asks again, and only one is expiry
The interval genuinely elapsed
The visitor consented, the record survived, and the period you configured ran out. This is the only one working as intended, and it should be the rarest cause in a support ticket. A visitor reporting weekly prompts is almost certainly not hitting this.
The record never survived
Far more common, and invisible from the settings screen, which shows what you asked for rather than what happened. Accept, then read what was actually written and with what expiry, and return a week later on Safari.
The record cannot be read where the visitor is standing
Consent stored on the www host does not read on the apex domain, and neither reads on a checkout sitting on another subdomain or domain. The record exists and the page asking cannot see it. Check the domain and path it is written against before assuming anything expired.
Something material changed, so the old consent no longer covers it
A new vendor, a new purpose, a new category of cookie. Consent is specific to what was described when it was given, so adding to that set invalidates the stored answer however recent it is. A tool still honouring the old record after the vendor list changed is quietly doing the wrong thing.
Why asking again more often than you need to is expensive
The compliance framing treats a shorter interval as automatically safer, and on the measurement side it is not free. Every prompt is another opportunity to decline, and those who decline are subtracted from everything you measure afterwards. A banner reappearing because the record was capped at seven days therefore earns a lower acceptance rate than the identical banner asking once a year, without anybody choosing that trade or seeing it in a dashboard.
That sits on top of what consent removes anyway: measured across Amplio Data client implementations at around 34% of sessions, which is a measured range and not a guarantee. A durability fault adds to it and returns nothing, which makes it one of the few consent problems that is purely a loss. What a denial does to reporting is in what happens to GA4 data when users reject cookies, and whether you send any signal on denial depends on basic rather than advanced Consent Mode.
So the honest answer is: as long as your regulator accepts, and not one visit less by accident. Pick the interval deliberately, then confirm the record actually lives that long. Those are two separate pieces of work and only the first has a settings screen.
Velo sets the consent record from the server rather than from a script, so it is not the seven day cap that decides how long it lasts, and prompts again when the vendor set changes rather than on a timer alone. No tool can outlast a visitor who clears their storage, and none should claim to. The mechanism is on the product page.
Common questions
What people ask about this topic.
How long does cookie consent last, and when should the banner ask again?
The GDPR sets no expiry period for cookie consent, and no article names twelve months. Guidance fills the gap: the European Data Protection Board recommends refreshing at appropriate intervals, and national supervisory authorities have each set their own figures, with commonly cited numbers between six and twenty four months and twelve the working default. Check your own authority rather than a published number, because blog figures routinely conflate different rules. The banner should ask again when that interval elapses, when the vendors or purposes change, or when no valid record can be read.
Why does my cookie banner keep reappearing for the same visitor?
Almost always because the consent record is not surviving, not because it expired. A record written by JavaScript as a first party cookie is capped by Safari at seven days, so a site configured for twelve months still asks Safari visitors again weekly. Local storage is cleared after roughly seven days without a visit. The other common cause is scope: consent stored on www does not read on the apex domain, and a checkout on another subdomain sees nothing.
Does GDPR say cookie consent expires after 12 months?
No. The twelve month figure is convention and guidance rather than law, and it does not appear in the regulation. It is widely used because it sits inside every supervisory authority's recommended range except the strictest, so renewing annually is defensible in most of Europe. If you serve French visitors, plan against the shorter figure. Treat any published interval as a maximum, never as a promise about how long the record will actually live.
When does consent need to be collected again even though it has not expired?
Whenever what you are asking permission for changes. Consent is specific to the purposes and vendors described at the moment it was given, so adding a vendor, a purpose or a category of cookie means the stored answer no longer covers your setup, however recent it is. A consent tool that keeps honouring the old record after the vendor list changed is failing quietly, because nothing in the interface reports it.
Does asking for consent again hurt my analytics?
Yes, and it is usually missed. Every additional prompt is another chance to decline, so a banner reappearing weekly because the record was not durable earns a lower acceptance rate than the same banner asking once a year. Consent already hides a meaningful share of traffic: measured across Amplio Data client implementations, around 34% of sessions, which is a measured range and not a guarantee.
Your banner, your consent,
your data — all in one place.
