Cleared Cookies, Fresh Banner: Why Consent Keeps Coming Back
A support ticket lands about once a month on every consent team: a visitor cleared their cookies, came back, and got the banner again. They call it a bug. It is three mechanisms doing exactly what they were told to do, and the fix is choosing a duration on purpose instead of inheriting one from a library default.
Start with the uncomfortable fact. Neither the ePrivacy Directive nor the GDPR sets a number for how long consent lasts. The ICO says so directly. What exists is regulator guidance, and it clusters around six months with remarkable consistency.
The guidance, regulator by regulator
The CNIL's recommendation of September 17, 2020 calls keeping the choice, consent and refusal alike, for six months good practice. The Garante's cookie guidelines of June 10, 2021 say the banner should not be shown again unless processing changes significantly, the site cannot tell whether a cookie was already stored, or at least six months have elapsed. The ICO's storage guidance, updated April 29, 2026, recommends six months as a suitable timeframe to request fresh consent after a refusal.
Spain's AEPD puts the ceiling higher: good practice is for consent to stay valid for no more than 24 months. The Digital Omnibus proposal would turn part of this into law, with Article 88a(4)(c) saying a controller shall not make a new request for the same purpose for at least six months after a refusal. Six months is the floor the regulators agree on. Twenty-four is the ceiling one of them states.
The library default is not the guidance
The CMP libraries default to something else entirely. Vanilla-cookieconsent ships at 182 days. Klaro's code says 120 days, though its sample config says 365, so copied configs usually say 365. Tarteaucitron and c15t both default to 365. A team that installs a library and never touches the expiry has chosen a year, not six months, and has no note explaining why.
The consent cookie's own lifespan has a second ceiling. The CNIL caps tracking cookies at 13 months, not extended on later visits, and raw analytics data at 25 months. Google Analytics 4 and Meta Pixel ship with 730-day defaults, which is exactly the kind of mismatch that draws a formal notice. Your consent record and your analytics identifiers are on different clocks, and the shorter one governs.
Then the browser deletes it anyway
Safari deletes a JavaScript-set consent cookie after seven days without a click, tap, or keypress on the site, whatever expiry you gave it. Chrome caps every cookie at 400 days. So a visitor who clears cookies, or who simply does not return for a week on Safari, will see the banner again no matter what your policy says. That is not a failure of your consent flow. It is the browser enforcing its own storage limit on top of yours.
The defensible setup is boring: six months for both accept and reject, the same duration for both, a re-ask only when processing changes or the period lapses, and a note in the record saying why six months was chosen. When the banner reappears after a cookie clear, the support answer writes itself.
Keep reading: What a Consent Record Has to Contain to Hold Up, When Your CMP Vendor List Changes, Who Has to Re-Consent?, The Quarterly Consent Audit: Five Checks That Catch a Broken Banner Before a Regulator Does cover the nearby cases in this series.
Frequently asked questions
How long should we remember a consent choice?
Six months is the figure regulators converge on: the CNIL, the Garante, and the ICO all treat about six months as good practice for both acceptance and refusal. Spain's AEPD allows up to 24 months. Pick six months as the default and record why.
Should accept and reject last the same amount of time?
Yes. Use the same duration for both. A short refusal window with a long acceptance window is the pattern regulators read as consent harassment, and the CNIL explicitly frames the six-month guidance as applying to consent and refusal alike.
Why does the banner come back after a week on Safari?
Safari deletes a JavaScript-set cookie after seven days without interaction on your site. That is the browser's own cap, not your CMP failing. Chrome caps cookies at 400 days. Neither limit is something your policy can override.
When should we ask again before the period lapses?
When the processing changes significantly, for example a new vendor category or a new purpose. A redesign or a new tracker list is also a re-ask event. Asking again because a quarter passed is not a reason; the guidance says to wait out the period.