What the Safari 7 Day Cookie Limit Actually Restricts

What is the Safari 7 day cookie limit?

Apple's Intelligent Tracking Prevention enforces the Safari 7 day cookie limit by capping the expiration of any cookie set through JavaScript to seven days from creation, regardless of the expiration date the script requested. A script that calls document.cookie and asks for a one-year expiry gets seven days instead; Safari silently rewrites the expiration and gives no error to the page that set it. The cap applies to the cookie's storage on the device, not to whether the site can keep asking a visitor to authenticate again.

Why did Apple introduce Intelligent Tracking Prevention?

Apple built Intelligent Tracking Prevention into WebKit to stop trackers from using long-lived, script-set cookies as a durable identifier once cross-site cookie access was restricted. Earlier ITP versions blocked third-party cookies from tracking a visitor across unrelated sites; trackers responded by writing their identifier into a first-party cookie on each site through JavaScript instead, which kept working because a first-party cookie was never blocked. The 7-day cap closed that gap by making any client-side cookie, first-party or not, expire on a short clock.

When does the cap drop to 24 hours instead of 7 days?

WebKit shortens the cap to 24 hours when a cookie is set through JavaScript immediately after a cross-site navigation whose URL carries link decoration, such as a query parameter used to pass a click or campaign ID, and the referring domain is one WebKit's on-device classifier has flagged as having cross-site tracking capability. This rule targets the exact pattern an ad click produces: a visitor clicks an ad, lands through a redirect carrying a tracking parameter, and the landing page immediately writes that parameter into a cookie. Without the shorter cap, that flow would have kept the full 7 days.

What survives the Safari 7 day cookie limit?

Cookies set directly by the server through a Set-Cookie response header survive the Safari 7 day cookie limit untouched, since the cap only rewrites the expiration of cookies a page sets through client-side JavaScript. A session cookie with no Expires or Max-Age attribute also survives the cap in practice, since it already ends when the browser session closes, sooner than seven days for most visitors. What does not survive is any identifier a tracking script depends on document.cookie to persist past a week without the visitor coming back to the site directly.

Do server-set HttpOnly cookies get capped too?

No. An HttpOnly cookie can only be created and read through a Set-Cookie response header from the server, since HttpOnly exists specifically to block JavaScript from touching the cookie at all, and Safari's script-cookie cap only applies to cookies JavaScript wrote. A login session cookie, a CSRF token, or any other cookie your backend sets and marks HttpOnly keeps whatever expiration the server assigned it, with no seven-day or 24-hour rewrite from ITP.

What does the Safari 7 day cookie limit break for attribution?

The Safari 7 day cookie limit breaks any attribution model that depends on a client-side cookie to connect an ad click to a conversion more than a week later, and shortens that window to a single day when the click carried a decorated tracking URL. A B2B sale with a three-week sales cycle, an affiliate commission claimed on a return visit ten days after the first click, or a remarketing campaign measuring a two-week attribution window all lose the client-side cookie linking the original click to the eventual conversion on Safari, well before the conversion happens. The visitor is not lost from the site; only the JavaScript-set cookie that would have connected two separate visits is gone.

How do teams work around the Safari 7 day cookie limit?

Teams work around the Safari 7 day cookie limit by moving the cookie-setting step from client-side JavaScript to the server, since a Set-Cookie response header from your own first-party domain is not subject to either ITP cap. Server-side tracking sets the identifier cookie as part of the HTTP response instead of a script call, and marking it HttpOnly removes it from ITP's scope entirely along with blocking any client-side script from reading or tampering with it. Reviewing which of your first-party and third-party cookies are still set by JavaScript is the first step toward finding every identifier this cap can quietly expire.

The other path is to stop depending on any cookie for attribution. Flowsery ships cookie-free, EU-hosted analytics that connects sessions to revenue without writing an identifier to a cookie at all, so a visitor's Safari settings and Apple's expiration rules have nothing to expire in the first place.

Frequently Asked Questions

Does the Safari 7 day cookie limit apply to Chrome or Firefox?

No. The 7-day and 24-hour caps come from WebKit's Intelligent Tracking Prevention, which ships in Safari and every browser built on WebKit, including Safari on iOS and iPadOS. Chrome and Firefox run their own separate tracking-prevention systems with different rules and different cap lengths.

Can a site reset the 7-day cookie clock?

Only if the cookie is rewritten by the server through a Set-Cookie header, or if the visitor returns to the site directly and the page's script writes the cookie again before the seven days run out; either action starts a fresh seven-day window. A cookie that is never refreshed before day seven expires and is gone, and the visitor has to be re-identified as if the cookie had never existed.

Does the Safari 7 day cookie limit block third-party cookies too?

Third-party cookies are blocked by Safari outright under a separate ITP rule and never reach the seven-day question at all. The 7 day cookie limit specifically targets first-party cookies that JavaScript sets, which is the workaround trackers turned to once third-party cookies stopped working.

Does clearing Safari's website data reset the cookie cap?

Clearing website data deletes the cookie immediately instead of resetting its cap, so the site starts from zero the next time the visitor arrives, exactly as if seven days had already passed. The cap governs how long an existing cookie can live, not how the cookie behaves once it has been manually removed.

Is local storage capped the same way as cookies?

This page covers only the cookie cap, since that is the specific rule described here. Client-side storage mechanisms other than cookies fall under different parts of Intelligent Tracking Prevention, with their own conditions for when a domain's stored data gets cleared, so treat cookie caps and other storage caps as separate rules instead of assuming one implies the other.

Why do some sites still see attribution work past 7 days on Safari?

A site keeps working past seven days when it never depended on a JavaScript-set cookie for the link between click and conversion, because it sets the identifying cookie from the server with Set-Cookie, or because it re-identifies the visitor through a login instead of a cookie at all. Sites that measure conversions without any cookie, through server-side session matching or a cookie-free analytics approach, are never subject to the cap because there is no script-writable cookie for ITP to expire.

Does the Safari 7 day cookie limit apply to cookies JavaScript reads, or only cookies it sets?

The cap only applies when JavaScript writes a cookie through document.cookie, not when it reads one. A server-set cookie that a script merely reads keeps whatever expiration the Set-Cookie header assigned, since only script writes get rewritten. HttpOnly cookies remove even that read access, but the write rule already covers reading for any cookie JavaScript can otherwise see.

Does an affiliate link trigger the 24-hour cookie cap instead of 7 days?

Only if the affiliate link carries decorated tracking parameters, such as a click or campaign ID in the URL, and the referring domain is one WebKit's classifier has flagged for cross-site tracking. An affiliate link without both conditions still falls under the standard 7-day cap for any cookie set through JavaScript. The affiliate example in this post, a commission claimed ten days after the first click, already misses even the 7-day window, so the shorter cap would only make that gap worse.

Does the Safari 7 day cookie limit apply to third-party analytics scripts too?

Yes, if the script writes its cookie through document.cookie on the page's own domain, since the 7-day cap covers any client-side cookie, first-party or not. What matters to ITP is how the cookie was set, not which company's script set it. A third-party analytics tag that still relies on document.cookie for its identifier loses that identifier after seven days exactly like a first-party tracking script would.

Can the 24-hour cap shorten a cookie that already existed before the ad click?

The 24-hour cap only kicks in for a cookie set immediately after the decorated cross-site click itself; it does not reach back and shorten a cookie that already existed on the device. A cookie written by JavaScript before the visitor clicked the ad keeps running on whichever cap applied when it was created, typically the standard 7-day window. The click can start a new, more limited cookie, but it doesn't retroactively touch one already ticking down.