In 2026, each major browser applies its own cookie restrictions. The combined effect — Safari’s lifetime caps, Firefox’s partitioning, plus ad blockers — means client-side tracking misses 20-40% of visitors before accounting for consent rates. This note documents what each browser does and how those restrictions interact with server-side cookie setting.
Safari: Intelligent Tracking Prevention
Safari’s Intelligent Tracking Prevention (ITP) applies the strictest restrictions. iOS compounds its reach: every browser on iOS runs on Apple’s WebKit engine and is subject to ITP.
Cookie lifetime caps. Cookies set via JavaScript (document.cookie) are capped at 7 days. When a user arrives through a link containing tracking parameters like gclid or fbclid, that cap drops to 24 hours — Safari detects these as cross-site tracking vectors and treats the session as suspect. After 30 days of inactivity, Safari purges all site data entirely.
IP address checks (since Safari 16.4). ITP now also inspects the IP address of any server setting cookies. If your tracking subdomain (say gtm.yourdomain.com) resolves to a different IP range than your main website, Safari treats those cookies as third-party even though they’re set under your domain. The 7-day cap applies regardless of whether the cookie was set by JavaScript or HTTP header.
Safari 17 additions. Advanced Tracking Protection can block GTM and GA CDN domains outright. Link Tracking Protection strips gclid and fbclid parameters from URLs before your code can read them — so the tracking parameter never reaches your tag, let alone gets stored.
The iOS multiplier. Every browser on iOS — Chrome, Firefox, Edge, every third-party browser — runs on Apple’s WebKit engine. ITP restrictions apply to all iOS browsers, not just Safari. This affects roughly 27% of mobile traffic regardless of which browser the user opened.
Firefox: Total Cookie Protection
Firefox takes a different architectural approach. Rather than capping cookie lifetimes, it partitions the cookie store.
Third-party cookie partitioning. Third-party cookies can still be set, but each top-level site gets its own isolated “cookie jar.” A cookie set by tracker.example.com on site-a.com is invisible when the same user visits site-b.com. Cross-site tracking that depends on shared identifiers across domains breaks completely. But first-party cookie lifetimes are not restricted — a distinction that matters when evaluating server-side cookie approaches.
Bounce Tracking Protection. In Strict mode, Firefox detects redirect-based tracking (where a URL passes through a tracker domain mid-redirect) and clears data from those trackers. This affects some affiliate and redirect-heavy ad network flows.
Firefox’s approach is meaningfully different from Safari’s. It targets the cross-site tracking use case specifically rather than applying blanket lifetime restrictions. A first-party analytics implementation that sets cookies directly under your domain is not impacted by Firefox’s restrictions the way it’s impacted by Safari’s.
Chrome: The Permissive Exception
Chrome keeps third-party cookies enabled by default. After the Privacy Sandbox project’s effective collapse in 2024 — Google chose not to deprecate third-party cookies — Chrome’s ~67% global market share still allows traditional cross-site cookie tracking.
The main restriction is SameSite=Lax as the default cookie attribute. This means cookies only travel with top-level navigations (a user clicking a link), not with embedded cross-site requests (iframes, fetch calls from a third-party script). For most analytics implementations, this is a minor constraint rather than a data loss issue.
Chrome is the exception in the current industry landscape. Its permissiveness affects aggregate data loss numbers, but sites with significant Safari or ad-blocker exposure see losses that Chrome’s permissiveness does not offset.
The Combined Effect
Between Safari’s caps (hitting ~27% of mobile traffic), Firefox’s partitioning, and ad blockers (used by approximately 31.5% of global internet users), client-side tracking realistically misses 20-40% of visitors for most sites. The variance is wide because it depends on your audience mix.
Sites with younger demographics or high mobile usage skew toward the higher end. B2B sites with desktop-heavy, enterprise-network traffic tend toward the lower end — though ad blockers are heavily concentrated among technical users, so B2B isn’t automatically safe.
This data loss is the fundamental reason server-side cookie setting exists as a technical practice. It solves the Safari ITP problem specifically by setting cookies via HTTP header from a same-domain server rather than via JavaScript — bypassing the 7-day cap. But it doesn’t solve ad blockers, and it doesn’t solve the IP address check introduced in Safari 16.4 without additional infrastructure.
The consent layer interacts with this independently. Browser restrictions reduce signal regardless of consent status. Consent mode operates on top of the remaining signal, further reducing what you observe when consent is denied. Both forces compound, and the EU legal framework adds a compliance dimension that constrains what you can do even with server-side infrastructure.
Practical prioritization depends on audience composition: Safari share (split mobile/desktop), iOS share, and measured ad-blocker rate. These numbers determine the relative impact of each restriction.