Safari ITP’s 7-Day Cookie Kill vs Server-Set 400-Day Cookies: The Gap

What is Safari ITP’s 7-day cookie limit?

Safari’s Intelligent Tracking Prevention caps all JavaScript-set cookies to 7 days of storage, and cookies from domains Safari classifies as cross-site trackers are capped at 24 hours — regardless of the expiry date set by the script (WebKit, 2025). Set a cookie for 400 days in JavaScript, and Safari will delete it in 7. Set it for a year, and Safari will delete it in 7. The expiry date you write is irrelevant.

ITP operates at the browser engine level. It’s not a preference the visitor toggles on. It’s not a setting buried in Safari’s privacy tab. It runs by default on every Safari installation — every iPhone, every iPad, every Mac — and it can’t be turned off. When a JavaScript tag sets a cookie via document.cookie, Safari intercepts the operation, checks whether the domain has cross-site tracking capabilities, and applies the cap.

The 24-hour cap is the one that hurts most. If Safari classifies your tracking domain as a cross-site tracker — which it will, if your analytics or ad pixels load from a known tracking domain — the cookie survives exactly one day. A customer who clicks your Google Ad on Monday and returns on Wednesday has already lost attribution.

Safari ITP caps JavaScript-set cookies to 7 days (24 hours for classified trackers), regardless of the expiry date set by the script (WebKit, 2025).

How do server-set cookies bypass ITP?

Server-set cookies use the HTTP Set-Cookie response header, which Safari treats as genuine first-party storage — ITP’s 7-day cap applies only to cookies set via document.cookie in JavaScript, not to cookies set by the server itself (WebKit, 2025). The mechanism is architectural: the cookie comes from the server’s HTTP response, not from a script running in the browser.

Here’s what happens technically. A visitor lands on your WooCommerce store. Your server processes the request and returns an HTTP response. In that response, a Set-Cookie header sets a first-party cookie — say, a visitor ID with a 400-day expiry. Safari sees the cookie arriving from the server that served the page, from the same domain the visitor is on, via an HTTP header. It has no basis to classify this as a tracking cookie. It stores the cookie with the full 400-day expiry.

Compare that to the JavaScript approach: a tag manager loads, runs a script, and that script calls document.cookie to set a tracking cookie. Safari sees a script — potentially a third-party script — setting storage in the browser. ITP flags it and caps the expiry to 7 days. Same domain, same cookie name, same visitor — but a fundamentally different mechanism, and a fundamentally different outcome.

Related: Server-Side Cookie Setting: Why Your Server Can Set Cookies That Safari Cannot Kill

How much Safari traffic do WooCommerce stores typically have?

Safari holds 18.9% of global browser share — but in English-speaking B2C mobile markets like the US, UK, and Australia, its share reaches 25–40% of WooCommerce traffic (StatCounter, 2026). That’s not a niche segment. That’s a quarter to nearly half of your visitors — every one of them subject to ITP’s cookie restrictions.

The share skews higher on mobile. In the US, iPhone holds roughly 55% of the mobile market, and every iPhone browser — Chrome, Firefox, Edge, whatever the label — uses WebKit under the hood. That means ITP applies to all of them. A visitor browsing your store in “Chrome” on their iPhone is still subject to Safari’s 7-day cookie cap. The browser name on the icon doesn’t matter. The rendering engine does.

For WooCommerce stores in markets with high Apple adoption — the US, UK, Australia, Japan, Scandinavia — the attribution gap affects the largest single segment of their traffic. A store losing attribution on 35% of its visitors isn’t experiencing a rounding error. It’s flying partially blind on its highest-value traffic.

How does the 7-day limit affect WooCommerce revenue attribution?

Any customer who takes longer than 7 days from first click to purchase loses attribution entirely on Safari — the cookie that linked their purchase to the original ad click or campaign has already been deleted by ITP (Simo Ahava, 2025). The revenue registers. The attribution doesn’t. The ad platform reports zero conversions for a campaign that drove real sales.

Average WooCommerce purchase consideration runs 2–30 days, with items over $100 typically taking 14–28 days (WooCommerce, 2025). That’s two to four times longer than ITP’s 7-day window. A customer clicks a Google Ad on day 1, browses your product pages, leaves, comes back on day 10, and purchases. By day 10, Safari has deleted the gclid cookie. Google Ads has no record of the original click. The purchase appears as direct traffic — an organic miracle that was actually a paid acquisition.

The downstream cost isn’t just inaccurate reports. It’s bad decisions. When your ad platform shows low ROAS because it can’t see the conversions it drove, you reduce spend on campaigns that were actually profitable. You’re optimizing against phantom data, cutting the campaigns that work and keeping the ones that merely look good in a 7-day window.

Average WooCommerce purchase consideration is 2–30 days — anything over 7 days breaks Safari attribution entirely (WooCommerce, 2025).

Related: Your ‘First-Party’ Cookies Still Die in 7 Days: Why Safari ITP Caps JavaScript Cookies and Only a True First-Party Server Survives

What does a custom subdomain do for server-side tracking?

A custom subdomain like track.yourstore.com causes Safari to treat tracking cookies as first-party by origin — the cookie is set by your domain’s server, from your domain’s subdomain, and ITP has no basis to cap it (WebKit, 2025). It’s not a trick. It’s the definition of first-party: same registrable domain, server-set, no cross-site tracking classification.

The subdomain approach works because ITP’s classification operates at the registrable domain level. If your store is yourstore.com and your tracking endpoint is track.yourstore.com, they share the same registrable domain. A cookie set by track.yourstore.com via an HTTP response header is, by definition, a first-party cookie for yourstore.com. Safari has no mechanism to distinguish this from any other server-set cookie on your domain — because it is a server-set cookie on your domain.

Contrast this with a third-party tracking domain like analytics.google.com or a GTM server container on sst.googletagmanager.com. Safari knows those aren’t your domain. Even if the cookie is server-set, the origin is cross-site, and ITP can apply restrictions. The subdomain on your own domain eliminates that classification entirely.

Cookie Method	Safari ITP Lifetime	Mechanism
JavaScript document.cookie	7 days (24h if classified tracker)	Script sets cookie in browser
Third-party server Set-Cookie	Varies (may be capped)	Non-matching domain sets cookie
First-party server Set-Cookie	Up to 400 days	Your server sets cookie via HTTP header
Custom subdomain server Set-Cookie	Up to 400 days	Your subdomain server sets via HTTP header

Does ITP affect Google Analytics and Google Ads differently?

Both are affected: GA4’s _ga client ID cookie is set by JavaScript and capped at 7 days, losing returning visitor identification; Google Ads’ gclid cookie is also JavaScript-set and loses click attribution after 7 days on Safari (Google, 2025). Different platforms, same mechanism, same 7-day cliff.

The GA4 impact is about identity. The _ga cookie is how Google Analytics recognizes a returning visitor. Without it, every visit after 7 days looks like a new user. Your “returning visitor” metrics deflate. Your cohort analysis breaks. Your user journey reports show a population of one-time visitors who somehow generate repeat revenue — because GA4 can’t connect the same person’s sessions across a week-long gap.

The Google Ads impact is about money. The gclid cookie stores the click identifier that links a purchase back to the ad that drove it. When ITP deletes it after 7 days, Google Ads can’t attribute the conversion to the click. The campaign that drove the sale shows no conversion. You lower the bid or pause the campaign. You’re not just losing data — you’re making worse decisions with the data you have left.

Related: How does server-side tracking help with first-party cookies?

Does returning visitor identification work on Safari without server-side tracking?

No — without server-side tracking, returning visitor identification drops to near zero after 7 days on Safari — the GA4 client ID cookie is deleted, so every returning visitor appears as brand-new, inflating new visitor counts and breaking cohort analysis (martech.org, 2025). Your most loyal customers look like strangers every time they come back.

The compounding effect is insidious. A customer visits your store on day 1 — new visitor. Returns on day 10 — new visitor (cookie deleted on day 8). Returns on day 18 — new visitor again. Purchases on day 20 — attributed as a first visit, direct traffic, no campaign credit. In GA4, this one customer looks like four different people, three of whom bounced and one of whom converted on their first visit. Every metric downstream of visitor identity is wrong.

Server-side tracking solves this because the visitor ID is stored in a server-set HTTP cookie that Safari doesn’t cap. The same visitor returns on day 10, 18, or 90, and the cookie is still there. GA4 sees one user across all sessions. Attribution works. Cohort analysis is accurate. The difference isn’t better tracking — it’s correct tracking.

Will Apple make ITP even stricter in future Safari versions?

Apple has consistently tightened ITP since its 2017 introduction — from 30-day caps to 7-day caps to 24-hour caps for classified trackers — and WebKit’s public tracker suggests further restrictions on remaining client-side storage mechanisms (WebKit, 2025). The trajectory is one-directional: every update removes another workaround.

The pattern is instructive. ITP 1.0 in 2017 capped third-party cookies at 30 days. ITP 2.0 blocked them entirely. ITP 2.1 capped first-party JavaScript cookies at 7 days. ITP 2.3 introduced the 24-hour cap for classified trackers. Each version closed a loophole that the tracking industry had found in the previous version. Apple isn’t reacting to specific tools — they’re systematically eliminating every client-side storage mechanism that can be used for cross-site tracking.

For WooCommerce store owners, the lesson is architectural. Any solution that depends on JavaScript setting storage in the browser is building on ground Apple has explicitly committed to removing. Server-set cookies survive because they’re genuinely first-party — and that’s a distinction Apple has no reason to eliminate, because first-party storage is how the web itself works. Building on server-set cookies isn’t betting on a workaround. It’s building on the foundation Apple is protecting.

For WooCommerce stores that need server-set first-party cookies without a GTM server container, Transmute Engine sets HTTP cookies directly from your WordPress server on your store’s own domain — automatically treated as genuine first-party by Safari ITP, extending cookie life from 7 days to 400+ days across GA4, Google Ads, Meta, and TikTok.

Key Takeaways

• 7 days is the ceiling: Safari ITP caps all JavaScript-set cookies to 7 days, and classified tracker cookies to 24 hours — no exceptions.
• Server-set cookies bypass ITP: HTTP Set-Cookie headers from your own domain are treated as genuine first-party and persist for 400+ days.
• 25–40% of your traffic is affected: Safari’s market share in English-speaking markets means a quarter to nearly half of visitors hit ITP.
• The attribution gap is a revenue gap: purchases taking longer than 7 days lose all campaign attribution on Safari — you can’t optimize what you can’t see.
• Custom subdomains make it first-party: track.yourstore.com on your own domain means Safari has no basis to restrict the cookie.
• GA4 and Google Ads both break: the _ga client ID and gclid cookies are JavaScript-set and subject to the 7-day cap.
• ITP will only get stricter: Apple’s trajectory since 2017 is one-directional — every update closes another client-side loophole.
• Server-set is the foundation, not the workaround: Apple protects genuine first-party server cookies because that’s how the web works.

References

1. WebKit (2025). Tracking Prevention in WebKit. Source
2. Simo Ahava (2025). Server-Side Tagging in Google Tag Manager. Source
3. StatCounter (2025). Browser Market Share Worldwide. Source
4. WooCommerce (2025). WooCommerce Documentation. Source
5. martech.org (2025). How Server-Side Tracking Is Changing Digital Analytics. Source
6. Google (2025). GA4 Developer Guides — Data Collection. Source
7. Google (2025). About Auto-Tagging — Google Ads Help. Source