Cookie Lifetime Caps Are Rewriting the Definition of a Returning Visitor

Chrome's 400-Day Ceiling and Safari's Seven-Day Floor

Chrome caps cookie expiration at 400 days, per Chrome for Developers. Cookies requesting longer lifespans are not rejected; their expiration is silently reset to 400 days. A site can extend this by issuing a fresh cookie with the same name when the user returns, effectively refreshing the clock.

Safari operates on a different scale entirely. Intelligent Tracking Prevention caps JavaScript-written cookies at seven days, according to Zoho Cares' summary of Apple's policy. Arrive via a decorated link carrying query strings or fragments from a tracking domain, and ITP 2.2 drops that lifetime to 24 hours. ITP 2.3 extended the 24-hour rule to website cookies and added non-cookie local storage to the seven-day limit. Treasure AI's documentation states that Safari caps script-set cookies, localStorage, and IndexedDB when the user stays inactive.

The gap between 400 days and seven days is not trivial. A publisher running cross-browser analytics must reconcile two entirely different decay curves in the same dashboard.

How One Person Becomes Two Visitors

Adobe's example clarifies the counting mechanism. Under a seven-day expiry, a user returning within seven days receives a seven-day extension. Return on day eight, and the original cookie has expired. The analytics package sets a new identifier. The user is logged as a new visitor.

This inflates new-visitor counts mechanically. A genuine returning audience, measured honestly, suddenly appears to churn. The "returning visitor" rate falls not because the audience changed, but because the recognition token expired between sessions.

The distinction matters for anyone presenting retention data to stakeholders. A 30% drop in returning visitors can trigger content strategy reviews, budget reallocations, team changes—when the underlying audience behavior never shifted.

What Survives, What Decays, and What the Policies Actually Say

Not all storage faces identical treatment. Adobe distinguishes SameSite=None, Lax, and Strict settings, with None enabling cross-site access and requiring Secure; Lax permitting only top-level safe-method cross-site requests; Strict blocking third-party requests entirely. Chrome's cookie reference maps no_restriction, lax, and strict modes to these SameSite values.

Chromium's SameSite FAQ adds a specific edge case: cookies at most two minutes old are sent on top-level cross-site POST requests. Chrome DevTools displays expiration as either a date, a maximum age, or Session for session cookies.

A primary-source WebKit statement naming Safari's exact first-party cookie lifetime cap has not been found. Summaries from Adobe, Zoho Cares, and Treasure AI cite seven days for script-set storage, but server-set versus script-set distinctions rely on secondary sources.

What is known: Safari's ITP specifically targets script-set cookies via document.cookie. Server-set cookies follow different rules. Local storage and IndexedDB share the seven-day inactivity limit. A measurement program relying on JavaScript-based identifiers faces a harder ceiling than one using server-set headers.

Where the Dashboard Cracks First

Returning-visitor counts are the first casualty, but not the only one. Time-to-conversion metrics lengthen artificially when intermediate sessions vanish from the record. A user who researches on Monday and converts on Friday appears as a same-session conversion if the Monday cookie expired—compressing a genuine multi-day journey into a single visit.

Multi-session attribution collapses similarly. Cohort retention curves flatten not because users stopped returning, but because the identifier linking their sessions expired. The cohort never "churned" in behavioral terms. It was simply reclassified as new.

Adobe's documentation notes that authenticated measurement—limited to signed-in users—preserves cross-session identity regardless of cookie expiry. The tradeoff is coverage: it measures only the subset willing to authenticate.

The Baseline Problem

Comparing returning-visitor rates across a policy change is meaningless without restating history under the new rule. A chart showing January 2024 at 35% returning visitors and January 2025 at 22% does not demonstrate audience loss if January 2024 was measured under 400-day Chrome cookies and January 2025 under seven-day Safari constraints applied to the same traffic mix.

The honest presentation requires two numbers: the rate under the old rule, and the rate under the new rule, calculated retroactively on the same historical data. Most analytics platforms do not provide this restatement automatically. The analyst must extract raw events and rebuild the counts.

What to Ask Before Paying for a Workaround

Vendors promise server-side cookie setting, fingerprinting hybrids, and probabilistic identity graphs to restore pre-cap measurement fidelity. Two questions precede any purchase: Does the workaround comply with the browser's published policy, or does it rely on behavior the vendor could patch tomorrow? And does the cost of the fix exceed the value of the precision lost?

The 400-day Chrome cap leaves substantial runway for most publishers. The seven-day Safari ceiling bites harder, particularly for sites with weekly or longer return cycles. A travel planner, a B2B research hub, a seasonal retailer—all face systematic undercounting of genuine return visits.

The Chrome DevTools cookie panel displays expiration directly. Check your own first-party identifiers. If your analytics cookie shows a 365-day expiry but your Safari traffic dominates, the actual effective lifetime is seven days or less. The dashboard will not warn you. The returning-visitor line will simply drift downward, and someone will ask why the audience is leaving.