Safari's Intelligent Tracking Prevention (ITP): Frequently Asked Questions

Since its initial release in September 2017, WebKit has shipped five major iterations of Intelligent Tracking Prevention (ITP), each tightening privacy protections for Safari users and narrowing what AdTech and MarTech platforms can do with browser-based identifiers.

This FAQ covers what ITP is, how it works mechanically, which restrictions it imposes, how it has evolved, who is affected, and what practical workarounds exist.

What Is Intelligent Tracking Prevention?

Intelligent Tracking Prevention (ITP) is a privacy feature built into Apple's Safari web browser. Its primary purpose is to block third-party cookies — commonly referred to as trackers — that identify and follow users across different websites, a practice known as cross-site tracking. Beyond third-party cookies, ITP also restricts the lifespan of other browser storage mechanisms that can be repurposed for user identification, including first-party cookies and local storage.

ITP is developed and maintained by WebKit, the open-source browser engine that powers Safari.

How Does Intelligent Tracking Prevention Work?

ITP uses a machine-learning model called the Machine Learning Classifier to identify which domains have cross-site tracking capabilities. Once a domain is flagged by the classifier, specific limitations are applied to cookies and other storage that those domains create or interact with.

The classifier evaluates domains based on behavioural signals and cross-site resource loading patterns, not solely a manually maintained blocklist.

What Restrictions Does ITP Place on Cookies and Other Browser Storage?

Here is a summary of the key restrictions:

• Third-party cookies are blocked by default.
• First-party cookies set via JavaScript's document.cookie expire in 7 days. If the cookie is accessed within that window, the expiry resets for another 7 days.
• First-party cookies set via document.cookie by a tracking domain that also uses link decoration expire in 24 hours. Accessing the cookie within that 24-hour period extends it by another 24 hours.
• All non-cookie browser storage (e.g., local storage) expires after 7 days. Accessing the data within those 7 days extends the expiry by another 7 days.
• ITP 2.3 specifically deletes all non-cookie data after 7 days when the referring domain has been classified as a tracking domain and the referring URL contains link decoration.
• Companies like Google and Facebook must obtain user consent via the Storage Access API before setting cookies through embedded widgets (such as "Sign in with Google/Facebook" buttons).

How Has ITP Evolved?

Intelligent Tracking Prevention was announced in June 2017 and first released alongside Safari 12 and iOS 11 in September 2017. Each subsequent version has introduced additional restrictions:

The trajectory is clear: each release closes workarounds that emerged after the previous one.

Which Companies or Services Are Affected by ITP?

AdTech Vendors

The loss of reliable cross-site identification hits AdTech platforms hardest. Without the ability to recognize users across different websites, vendors cannot run cross-site ad targeting, enforce frequency capping, or measure campaign performance across multiple publishers and advertisers.

Publishers

When advertisers can't identify audiences on a publisher's inventory, they are unwilling to pay as much for it. The result is lower CPMs and reduced overall ad revenue for publishers with significant Safari traffic.

Advertisers

Advertisers are less directly impacted than publishers or AdTech vendors — they can adjust targeting criteria to de-prioritize Safari traffic — but the restrictions make it harder to reach intended audiences at scale and reduce the precision of attribution.

MarTech Vendors

Most MarTech platforms were largely unaffected by the earliest ITP versions, since the initial restrictions targeted first-party cookies originating from known tracking domains, a pattern less common in MarTech. However, ITP 2.1's blanket 7-day expiry on document.cookie-set first-party cookies brought MarTech tools into scope, since virtually all client-side analytics and personalization platforms rely on this mechanism.

What Are the Practical Workarounds for AdTech Companies?

Most AdTech processes that depend on third-party cookies — particularly cross-site user identification — are fundamentally restricted under ITP. That said, a few approaches remain viable:

Click-through attribution is still achievable. A unique click ID (or visitor ID) can be passed in the destination URL. The destination site captures and stores this ID via a JavaScript tag, then notifies the ad server. Because this is a first-party operation on the destination domain, it works within ITP's constraints — though the attribution window is limited to 24 hours under ITP 2.2 if the referring domain is classified as a tracking domain (which applies to the majority of AdTech platforms), or 7 days under ITP 2.3.

Second-party data partnerships can implement a compatible workaround by exchanging identifiers between partner sites or domains owned by the same entity. The mechanism involves passing IDs via URL parameters and then storing them in first-party cookies on each respective domain.

Local storage as an ID store was once a viable fallback, but ITP 2.3 closed this path for classified tracking domains using link decoration — non-cookie data is purged after 7 days under those conditions.

What Are the Practical Workarounds for Analytics and MarTech Companies?

The 7-day first-party cookie expiry introduced in ITP 2.1 means that any user who returns to a site more than seven days after their last visit will appear as a new visitor in analytics and MarTech tools, leading to inaccurate user counts and session data.

Industry analyst Simon Ahava has documented several workarounds in his ITP 2.1 blog post, including:

• Setting first-party cookies server-side via the HTTP response header rather than JavaScript — cookies set this way are not subject to the 7-day cap
• Storing identifiers in local storage as a complement to cookie-based tracking (though this itself is subject to the 7-day non-cookie storage cap under later ITP versions)
• Using a reverse proxy server to route requests so that third-party analytics calls appear to originate from the first-party domain

The server-side cookie approach is the most durable of these options, since it bypasses the document.cookie restriction entirely.

How Does ITP Affect Walled-Garden Advertising Ecosystems?

Platforms like Google, Facebook, and Amazon were largely insulated from ITP 1.0 and 1.1 because their primary data collection happens within logged-in, first-party environments. ITP 2.0 through 2.3 changed the calculus, particularly around widgets and cross-site attribution.

Before any of these platforms can set cookies via embedded widgets (such as social login buttons), users must now explicitly consent through the Storage Access API. Without that consent, no cookies can be written.

Additionally, all conversion attribution carried out via link decoration and first-party cookies is capped — at 24 hours under ITP 2.2, or 7 days under ITP 2.3 — when the referring domain is classified as a tracking domain.

Can Safari Users Still See Ads Under ITP?

Yes. ITP restricts tracking capabilities, not ad display itself. AdTech platforms can still serve ads in Safari; they simply cannot create or read third-party cookies in the process.

The distinction worth noting is between ITP and ad blockers. If a Safari user has an ad blocker extension installed, ads will not display at all — because ad blockers prevent ad tags from loading in the first place, which is a separate mechanism from ITP entirely.

Understanding where ITP's restrictions apply — and where they don't — is essential for anyone building or operating AdTech and MarTech infrastructure that depends on Safari traffic. The consistent direction of travel from WebKit is toward tighter restrictions, so architectures that rely on server-side data handling and first-party relationships are the most resilient long-term approach.