Safari Click ID Stripping: What Web-to-App Loses

Short answer: Safari does not strip ad click IDs from every visit. Since Safari 17 and iOS 17 it removes known tracking parameters from links before navigation in Private Browsing and from links shared in Mail and Messages, and it does the same in all browsing for users who turn on advanced protection. Since Safari 26 (September 2025), known fingerprinting scripts in normal browsing cannot read query parameters or the referrer, even though the URL keeps them. Safari 27 did not change these rules. The fix is first-party: read the click ID on your own server, keep your own campaign parameters, and carry context into the app through your own links.

A lot of 2026 commentary says "Safari now strips gclid and fbclid". The real picture is narrower, and that matters, because the fix depends on which case you are in. This post sets out what Apple and WebKit have actually documented, what that does to web attribution and web-to-app flows, and what you can do about it.

What is click ID stripping?

Click ID stripping is when a browser or app removes ad click identifiers, such as gclid or fbclid, from a URL before the landing page loads, or hides them from scripts on the page, so the visit cannot be matched back to the ad click.

Click ID: a unique value an ad platform appends to the landing URL so it can match a later conversion to one specific click. Google adds a gclid and Meta adds an fbclid.

Apple calls its version Link Tracking Protection. WebKit describes it as removing "a subset of query parameters" identified as used for cross-site tracking of users or clicks. Apple does not publish the list. Its own example removes a tracking parameter and keeps a campaign parameter, so treat any paid click ID as at risk and test your own URLs.

What does Safari actually remove, and where?

Safari removes known tracking parameters in three places: Private Browsing, links shared in Mail and Messages, and all browsing when the user opts in. Normal browsing keeps them in the URL.

Three details matter:

• Removal happens before the request. WebKit says values are removed "prior to navigation", so your server never sees them. No server-side tag can recover them.
• Safari 26 hides, it does not strip. Apple says advanced fingerprinting protection now extends to all browsing by default. WebKit says this stops known fingerprinting scripts from reading query parameters and the referrer, and from setting long-lived cookies or LocalStorage. The URL itself is unchanged.
• The setting path. On iPhone it is Settings, Apps, Safari, Advanced, Advanced Tracking and Fingerprinting Protection. Apple's Safari 26 guide says it is on by default for Private Browsing and can be turned on for all browsing.

Safari 27 added something else: WebKit's October 2026 post says Safari now blocks network access to identity resolution services that turn email addresses into tracking IDs. That affects browser-side identity tools, not click IDs in links.

What else does Safari do to stored click IDs?

Even when a click ID arrives, Safari's Intelligent Tracking Prevention (ITP) limits how long the browser keeps it:

• 7-day cap: cookies created in JavaScript and other script-writeable storage are deleted after 7 days of Safari use without user interaction on your site.
• 24-hour cap: on landing pages reached through a decorated link, ITP can cap cookies created in JavaScript to 24 hours.
• CNAME and IP cloaking: cookies set by a third-party server hidden behind your subdomain are capped at 7 days.

So a click ID saved only in the browser can be gone before a considered purchase or an app install a week later.

What does web-to-app lose?

Web-to-app attribution loses the link between the ad click and the install whenever the click ID never reaches the landing page, or is not carried from the page into the app link.

• Private Browsing and shared links. A user who opens your ad link in a private tab, or taps a link a friend sent in Messages, lands with no click ID. If your "get the app" button copies the click ID into the store link, there is nothing to copy.
• Fingerprinting-classified scripts. If a script Safari classifies as a known fingerprinter reads the landing URL to build the app link, it reads nothing in normal browsing too.
• Delayed installs. A visitor who installs days later, after the 24-hour or 7-day cap has cleared script-set storage, arrives at the app with no saved context.
• Web conversions. The same gaps hit web attribution: the purchase still happens, but it lands as direct or organic.

For the difference between the two measurement problems, see web attribution vs web-to-app attribution.

Apple documents these protections for Safari, Mail and Messages. It does not say they apply to in-app browsers inside other apps, so test those separately.

How do you fix it with first-party data?

You cannot recover a click ID Safari removed before the page loaded. You can stop losing the ones that do arrive, and make attribution depend less on them.

1. Read click IDs on your server. In normal browsing the full URL reaches your server. Capture gclid, fbclid and your UTMs from the landing request, before any script runs. This is the core of first-party tracking.
2. Store them against your own visitor ID. Set the identifier from your own server and domain, not from JavaScript and not through a CNAME to a vendor, since ITP's documented caps target those cases.
3. Put your own campaign parameters on every ad URL. UTMs or an internal campaign ID describe the campaign, not the person. Apple's own example keeps a campaign parameter, so these give you a fallback when the click ID is gone.
4. Get an identity early. Once a visitor signs up or logs in, attach the stored click ID and campaign to the user ID, so later web or app conversions join on the account, not the browser.
5. Carry context into the app through your own link. Build the "get the app" link on your domain with the campaign baked in, as a deferred deep link, so the first app open knows where the user came from.
6. Send conversions server-side. Send purchases and sign-ups to ad platforms from your backend with the stored click ID, rather than relying on a browser pixel reading the URL.
7. Measure the gap. Track the share of Safari landings with a UTM but no click ID. A rising share tells you how much the rules cost you.

Do not try to replace click IDs with device fingerprinting. Apple is explicitly blocking it.

How does Linkrunner handle this?

Linkrunner is a mobile and web attribution platform, and no tool, Linkrunner included, can read a click ID Safari removed before the page loaded. What it does is keep the rest of the chain first-party:

• Web attribution (beta): the Web SDK, currently in beta, measures visits, sign-ups and purchases on your website and credits them to the campaigns that drove them. Our guide to tracking UTMs through payment gateway redirects covers a related leak.
• Web-to-app flows: links are dynamic and deferred by default, on branded short links using your own custom domain. The Meta web-to-app guide covers Meta's flow.
• Matching: deterministic first, with IP and user-agent matching only as a fallback when no deterministic signal exists.
• Privacy controls: opt-in PII hashing and consent signals through setConsent.
• Open data: unrestricted CSV, API and webhook exports, so your server-side records and Linkrunner's can be joined.

August AI, a Linkrunner customer, turns web visitors into mobile patients at 6x higher conversion than the industry average.

Frequently asked questions

Does Safari remove gclid and fbclid?

In Private Browsing, in links shared through Mail and Messages, and in all browsing for users who opt in, Safari removes known tracking parameters before navigation. Apple does not publish the list, so assume ad click IDs are affected and test. In default normal browsing the URL keeps them.

What changed in Safari 26?

Apple extended advanced fingerprinting protection to all browsing by default. Known fingerprinting scripts can no longer read query parameters or document.referrer, or set long-lived script storage, but the URL your server receives is unchanged.

Did Safari 27 change click ID handling?

WebKit's Safari 27.0 and 27.1 release notes list no change to Link Tracking Protection. Safari 27 did add blocking of identity resolution services that turn email addresses into tracking IDs.

Are UTM parameters stripped too?

Apple says it targets parameters used to track users or clicks across sites, and its own example keeps a campaign parameter. UTMs describe campaigns, so they are the better fallback, but test your own URLs.

Can server-side tagging recover stripped click IDs?

No. When Safari removes a parameter before navigation, your server never receives it. Server-side capture protects click IDs that do arrive from script restrictions and storage caps.

Where to start

Open one of your own ad URLs in a Safari private tab, then send it to yourself in Messages, and check what reaches your server. That five-minute test tells you which of the cases above applies. If you want web and app attribution that keeps campaign context first-party, request a demo from Linkrunner and run the seven fixes above as your checklist.