How Safari's ITP works, one mechanism at a time: tracker classification, the 7-day storage cap, cookie blocking, referrer trimming, and what it can't stop.
"Does Safari block trackers?" has a short answer — yes — and a long one that is more useful. Intelligent Tracking Prevention (ITP) is not a single switch. It is a stack of separate mechanisms in WebKit, each aimed at a different way of carrying an identifier from one site to another: a classifier that labels tracking-capable domains, a hard block on third-party cookies, a cap on how long scripts can keep data, a trim on the referrer, and more. This guide takes them one at a time and, for each, asks the same three questions: what does it do, what does a tracker lose, and what does an ordinary site lose?
Key Takeaways
- ITP is a stack, not a feature. According to WebKit's Tracking Prevention documentation, it combines third-party cookie blocking, referrer downgrading, on-device tracker classification, storage deletion, and expiry caps.
- The "7-day limit" is about script-written storage. WebKit deletes cookies created in JavaScript, plus
localStorage, IndexedDB,sessionStorage, media keys and service worker registrations and caches, after 7 days of no user interaction with the site. - Third-party cookies are blocked outright. WebKit states there are no exceptions; access is granted only through the Storage Access API (and a temporary compatibility fix for popups).
- ITP is state-based defence only. It removes stored identifiers and shared storage. It does not stop a site from collecting data about its own visitors, and it is not an anti-fingerprinting system — WebKit handles fingerprinting through a separate set of changes.
- On iOS it covers every browser. Because all iPhone browsers render with WebKit, ITP behaviour is not something you get only by choosing Safari — see why every iOS browser is Safari underneath.
Where ITP Started, and Why the Docs Page Matters
WebKit introduced ITP in June 2017. The original announcement, Intelligent Tracking Prevention by John Wilander, framed it as a way to reduce cross-site tracking "by further limiting cookies and other website data," and it built on a default that was already old: since Safari 1.0, WebKit had stopped third parties from setting new cookies unless they already had some.
That original design has changed since. In 2017, a classified domain you had interacted with in the last 24 hours could still use its cookies as a third party, and one you had interacted with in the last 30 days kept its cookies but in partitioned form. The current WebKit documentation instead describes third-party cookie blocking as total. This is why a chronological version history is the wrong way to learn ITP — it ages badly. The maintained reference is WebKit's Tracking Prevention page, and the rest of this article follows that page.
Mechanism 1: Classifying Tracking-Capable Domains
What it does. ITP collects statistics on resource loads and matches them against known patterns of cross-site tracking. If a registrable domain matches a pattern, it is classified as having cross-site tracking capabilities. A machine learning model looks at three numbers: how many distinct sites the domain has appeared on as a third-party subresource, how many as a third-party iframe, and how many it has performed cross-site redirects under. In the 2017 announcement, WebKit says all data collection and classification happen on-device.
Two more patterns feed the same label. Repeated top-frame redirects (bounce tracking) count, even when the redirect is delayed by a couple of seconds. And tracker collusion propagates it: once a domain is classified, every domain that previously redirected to it is classified too, recursively through the redirect graph.
What a tracker loses. A classified domain has all its website data deleted unless it has had user interaction as a first party, or been granted storage access, within the last 30 days of browser use. A domain that only ever appears in the background never earns that interaction, so it never gets to keep anything.
What a normal site loses. Nothing, unless it looks like a tracker. A site you actually use gets interaction credit, and that is the exemption. The cost falls on legitimate embedded services that users rarely visit directly — a widget provider you never open in its own tab can be misread as a tracker.
Mechanism 2: Blocking Third-Party Cookies Entirely
What it does. WebKit's default cookie policy, in effect since Safari 1.0, disallows a third party from setting new cookies unless it already has cookies. ITP goes further: by default it blocks all third-party cookies, with no exceptions. Two related rules close the side doors. A latch mode means that once a request is blocked from using cookies, all redirects of that request are blocked too. And third-party HSTS is blocked: it can be set only by the first-party website, for its own host and registrable domain.
What a tracker loses. The classic mechanism: an ad or analytics domain loaded on many sites reads the same cookie on each. Under ITP that cookie is never sent, so the tracker sees a stranger every time.
What a normal site loses. Any embedded service that relied on a shared third-party cookie: single sign-on frames, embedded comment systems that recognise a logged-in user, payment widgets. They must ask for access explicitly (see Mechanism 6).
Mechanism 3: Capping Script-Written Storage
What it does. Two caps apply to storage created by JavaScript in a first-party context, because trackers running as first-party scripts were saving identifiers there:
- 7 days. ITP deletes all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction with the website. WebKit lists the affected stores: IndexedDB, LocalStorage, media keys, SessionStorage, and service worker registrations and cache.
- 24 hours for link decoration. Some trackers add "click IDs" as URL parameters and pick them up with script on the landing page. ITP detects that pattern and caps the expiry of cookies created in JavaScript on that landing page to 24 hours.
The clock is user interaction — a click, tap or keystroke; WebKit says scrolling does not count — not calendar time since creation. A site you use every few days keeps its data.
What a tracker loses. The long-lived first-party identifier that a third-party script wrote into a page's own storage. Any visitor who returns after a gap of more than a week looks like a new visitor to it.
What a normal site loses. Anything stored client-side that must outlive a week without a visit: a "remember me" flag set from JavaScript, a saved draft in localStorage, a preference cookie. Sites that need durable state should store it server-side or set it from a server response instead. WebKit's page also notes that home screen web apps are exempt from the 7-day cap and are kept isolated from Safari's own data.
Mechanism 4: Downgrading the Referrer
What it does. By default, all third-party referrers are trimmed to their origin, in both the HTTP Referer header and document.referrer. WebKit's example: a full referrer of https://www.social.example/feed?clickID=123456 shows up as https://www.social.example/.
What a tracker loses. The path and query string. A click ID or an article URL passed in the referrer no longer reaches the destination; only the site it came from does.
What a normal site loses. Fine-grained referral analytics. A site can still see which origin sent a visitor, but not which page or campaign parameters on that origin.
Mechanism 5: Redirect and Bounce-Tracking Countermeasures
What it does. Bounce tracking sends you briefly through a tracker's domain so that it runs as a first party and can read its own cookies. ITP counts top-frame redirects per domain and feeds them into the classifier from Mechanism 1. For a classified domain that has had user interaction or storage access but is found bouncing, WebKit says its cookies may be rewritten to SameSite=strict — so they stop being sent in cross-site navigation. Cookie-blocking latch mode (Mechanism 2) covers redirect chains.
There is a related countermeasure for CNAME cloaking: when a first-party-looking subdomain actually resolves to a third-party tracker, ITP caps the expiry of cookies set in the HTTP response to 7 days. WebKit applies the same cap to third-party IP-address cloaking. Our CNAME cloaking explainer covers the technique itself.
What a tracker loses. The ability to use a fleeting redirect through its own domain as a way to become first-party and retrieve its cookie.
What a normal site loses. Legitimate redirect-based flows, such as single sign-on hops or link shorteners, can look like bounces. The interaction exemption protects providers that users actually engage with. For the technique itself, see bounce tracking explained.
Mechanism 6: The Storage Access API as the Sanctioned Exception
What it does. ITP's blocking would break legitimate embedded services, so WebKit added the exception: a third-party frame can request access to its own first-party cookies through the Storage Access API, generally in response to a user gesture. MDN documents the API as document.hasStorageAccess() and document.requestStorageAccess(), with the grant scoped to a specific top-level site and embedded site pair. See MDN's Storage Access API reference for current behaviour and per-browser prompting differences.
WebKit's docs note that granted storage access is one of the two things (with first-party user interaction) that exempts a classified domain from having its data deleted.
What a tracker loses. The ability to obtain access silently. It has to ask, in context, after a real interaction, and the user or browser can refuse.
What a normal site loses. A small amount of friction: an embed that used to work invisibly needs one click and one API call.
The Partitioning Layer Underneath
Alongside the six mechanisms above, WebKit's docs describe a partitioning layer: third-party LocalStorage and IndexedDB are partitioned per first-party website and made ephemeral, third-party Service Workers are partitioned along with their cache and IndexedDB, and HTTP cache entries for third-party content are partitioned per first-party website. Entries created for domains classified as trackers are also flagged for verification: after seven days, a cache hit is treated as a miss, the resource is reloaded and compared, and the entry is discarded if the responses differ — a defence against cache-based identifiers like ETags. The general idea is covered in storage partitioning explained.
What ITP Does Not Do
This is the section most articles bury, so it is stated plainly.
- It does not stop first-party data collection. ITP targets cross-site tracking. A site can still recognise its own returning visitors, log what they do, and set cookies in its own HTTP responses. The caps described above apply to script-written storage; the WebKit documentation does not list ordinary server-set first-party cookies among the affected stores (the CNAME-cloaking case is the exception).
- It does not stop fingerprinting. A fingerprint is computed from browser and hardware signals and stores nothing, so there is nothing for ITP to delete, cap or partition. Read our browser fingerprinting guide for the mechanics, or run the fingerprint check to see what your own browser exposes.
- It does not make link decoration harmless. ITP caps the lifetime of script-written cookies on a landing page once it detects click IDs, but a server that receives a click ID in a request can still record it.
- It is not a substitute for signalling. The Do Not Track header asked sites nicely; ITP enforces. WebKit even removed its DNT flag because it "was used as a fingerprinting vector." See why DNT failed.
ITP and Fingerprinting Are Different Subsystems
It is easy to blur two things that WebKit keeps separate. ITP governs state: cookies, storage, referrers, caches and redirects. Anti-fingerprinting is a different set of changes, listed in a separate section of the same documentation page: requiring permission for the Device Orientation/Motion APIs, limiting what WebRTC reveals about attached cameras and microphones, restricting font availability to web fonts and system fonts, freezing the user-agent string between marketing versions, removing plug-in support on macOS, and declining to implement features such as Web Bluetooth, Web MIDI and the Battery Status API.
The two have different goals and different failure modes. ITP defeats an identifier that a tracker stores. Anti-fingerprinting shrinks the number of distinguishing signals available to an identifier that a tracker computes. Each state-based defence Safari shipped made the stateless route relatively more valuable to a tracker who still wanted cross-site linking — which is why a persistent visitor ID built from browser signals outlives all of the mechanisms above.
Frequently Asked Questions
Does Safari block trackers?
Yes, in several ways at once: it blocks third-party cookies, trims third-party referrers, classifies tracking-capable domains and deletes their data, and caps how long script-written storage lasts. It does not block all tracking — first-party collection and fingerprinting remain.
What is the ITP 7-day cookie limit?
It is a cap on script-writeable storage. After 7 days of no user interaction with a site, WebKit deletes cookies created in JavaScript and other script-writeable storage such as localStorage and IndexedDB for that site. Interacting with the site resets the clock.
Does ITP apply to Chrome or Firefox on iPhone?
Yes, because on iOS those apps render with WebKit — although the exact position is changing in some regions, as covered in why every browser on your iPhone is Safari. ITP's behaviour is a property of the engine, not of the Safari brand.
Can I turn ITP off?
WebKit's documentation ties the default cookie policy to Safari's "Prevent cross-site tracking" setting. Switching that off makes cross-site tracking easier and is rarely the right fix for a broken embed; the sanctioned route is the Storage Access API.
Does ITP stop browser fingerprinting?
No. ITP concerns stored state. Fingerprinting stores nothing, and WebKit's separate anti-fingerprinting measures reduce, but do not eliminate, what a fingerprint can be built from.
Conclusion
ITP works because it does not rely on one trick. Classification finds trackers by how they behave, cookie blocking removes the shared jar, the storage caps shorten what scripts can keep, referrer trimming removes URL detail, and the Storage Access API leaves a visible, gesture-gated way back for legitimate embeds. What it leaves alone is just as important: a site's own records about its own visitors, and any identifier that is calculated rather than stored. If you want to see that second category for yourself, run the fingerprint check in Safari and compare it with another browser.
Recommended Reading:
