Cookies with excessive lifetime

The Expires attribute names an absolute date, computed by the server and therefore dependent on its clock.

The Max-Age attribute names a number of seconds from now, which is relative and immune to clock differences.

When both are present Max-Age wins, which matters because a tag setting both with different values is not unusual.

A cookie with neither is a session cookie: it disappears when the browser closes, which is the right default for anything that does not need to persist.

An expiry already in the past is how a cookie is deleted, and one appearing in an inventory usually means a tag is removing something it previously set.

Measurement platforms want returning visitors recognised across a long window, since that is what makes attribution possible.

A longer default produces better-looking numbers for the platform, so there is no pressure on it to be short.

The value ships in the snippet and is configurable, which means it is a decision nobody was asked to make.

European guidance has converged on a thirteen-month ceiling for measurement cookies, and the defaults frequently exceed it.

Browsers now cap some cookie lifetimes independently, which limits the practical effect and does not change what your site is asking for.

Measurement and analytics cookies: thirteen months or less, which is the documented expectation in the European context.

Advertising cookies: the strictest category, and the one where a long lifetime is hardest to justify against a single consent.

Preference cookies — a chosen language, a dismissed banner: long is reasonable, because the visitor benefits from it persisting.

Consent records themselves: long enough not to re-ask constantly, short enough that consent is periodically refreshed.

Session and authentication cookies: as short as the product tolerates, and session-scoped where it tolerates that.

A visitor is identified across a period they did not meaningfully agree to, which is the substance of the objection.

The consent record and the cookie diverge: consent is asked again and the identifier from before it persists.

Every persistent cookie is transmitted on every request for its lifetime, which is a small transfer cost multiplied by a long time.

And the inventory grows: a site accumulates cookies from tags that were removed, because the cookies outlive the script that set them.

That last point is why the inventory is worth reading rather than assumed — the list usually contains entries nobody can account for.

Open the browser's storage panel and read the expiry column for each cookie.

Anything more than about a year on a measurement cookie is the finding.

Note which cookies are session-scoped, since those need no attention.

Compare the list against the cookies your policy documents, which is usually where the unaccounted-for ones become visible.

Check the configuration of each measurement tag, since the lifetime is nearly always a setting rather than a fixed value.

`cookies.expiration` reads the Expires and Max-Age values with the precedence rule applied, which is this problem directly.

`cookies.persistence` separates cookies that disappear when the browser closes from those stored on disk.

`cookies.inventory` and `cookies.count` build the list the lifetimes are read from.

`cookies.analytics` and `cookies.advertising` identify the categories where the ceiling matters most.

`cookies.javascript` states the coverage: cookies written by script after load are outside the HTTP inventory, and measurement tags frequently set theirs that way.

It does not tell you whether your configuration complies with anything, which depends on your jurisdiction, your audience and your purposes.

A thirteen-month figure is a documented expectation in one regulatory context rather than a universal rule.

A persistent cookie is not a defect: it is a choice that needs a purpose and a documented lifetime.

What is reported is the lifetime observed, so that the decision can be made rather than inherited.