What's hidden in a share link?

A phone-share link's tail of trackers reveals where you clicked from, which ad credited the click, and which campaign got the credit. Unpacked here.

A real share link, unpacked

Here's a typical link you'd see in a newsletter and might forward to a friend:

https://example.com/2026/spring-launch?utm_source=newsletter&utm_medium=email&utm_campaign=spring&utm_content=hero-cta&fbclid=IwAR0aBc&gclid=Cj0KCQ

The path — /2026/spring-launch — is the only part the destination server cares about. Everything after the ? is metadata being broadcast to whoever's analytics, ad networks, and pixels happen to be on the destination page.

utm_source=newsletter — Google Analytics attribution: the click came from a newsletter.
utm_medium=email — the channel was email (not social, not paid search).
utm_campaign=spring — the campaign bucket inside Google Analytics.
utm_content=hero-cta — which CTA on the page was clicked (publisher A/B tags it).
fbclid=IwAR0aBc — Meta's click identifier, tying the click to a Facebook session.
gclid=Cj0KCQ — Google Ads' click identifier, crediting the ad-account that paid for the click.

Who gets the data, and what they do with it

Three audiences read what's hidden in your share link:

The publisher's analytics tool (usually Google Analytics) reads utm_* tags and credits the visit to a campaign. It tells the publisher their newsletter is converting.
The ad networks (Meta Pixel, Google Ads conversion tag, TikTok Pixel) read their respective click IDs and report a “conversion” back to the platform that served the ad. They tell the advertiser the spend worked.
The destination site's own tools — and any third-party scripts on the page — get to see the tail too. A tag manager might fan the parameters out to a dozen downstream tools at once.

What it leaks about you when you forward it

Forwarding a link with this tail still attached has three effects:

Your forward gets credited to the original campaign. Whoever reads the analytics sees “one more click from the spring newsletter” — even though, from their reader's point of view, the click came from you.
The ad-network click IDs follow your share into someone else's browser. If the recipient's browser runs Meta Pixel or Google's conversion tag, those scripts report a pageview tied to *your* click identifier. Quietly inflated bookkeeping; minor but real signal back to the platforms.
Anyone snooping on the link (a logging proxy, a clipboard manager, a screenshot OCR) sees the tail too. utm_source=newsletter doesn't identify you, but it does reveal where you got the link.

Why per-app share buttons hide this from you

On the desktop, you'd see the URL bar and notice the tail. On a phone, the share sheet shows you an app icon, a thumbnail, and a button — the URL itself is hidden inside the share payload. That's the gap LinkClean fills: the share sheet runs the cleaning between the source app and whatever you forward to. The clean URL replaces the dirty one before the sheet closes.

Browser-extension cleaners can't do this. They only see what passes through the browser tab. They can't see the link you're about to forward from Mail, Slack, Messages, X, or Reddit — the apps where most sharing happens on a phone. That's the architectural reason LinkClean is a native iOS app, not a Safari extension.

Recognizing the most common hidden parameters

Once you've seen the pattern, you start spotting these everywhere. The most common ones — all in LinkClean's default catalog, all stripped by default:

utm_source, utm_medium, utm_campaign, utm_term, utm_content — Google Analytics campaign tags.
fbclid — Meta click identifier.
gclid, gbraid, wbraid — Google Ads click identifiers.
msclkid — Microsoft Ads.
ttclid — TikTok Ads.
yclid — Yandex Ads.
mc_eid — Mailchimp email identifier (per-recipient unique).
_fbp, _fbc — Meta cookie-mirroring URL parameters.
si= on YouTube / Spotify — share-identifier tokens that credit who pressed Share.
t= / s= on x.com — share-token equivalents (host-scoped — t= on YouTube is timestamp, NOT a tracker).

The simple rule

If you didn't put it there on purpose, it's tracking. Paths are functional. Query strings are mostly metadata. Strip the metadata before you share — LinkClean's job is to make that automatic, on every surface where sharing happens on iPhone.

Frequently asked

Is the URL the only thing that gets shared?

On a share sheet, usually yes — the share payload is the URL plus maybe a title. The “hidden” we're talking about is *within* the URL itself: the tail of trackers after the ?. The fix is to clean that tail before the share happens.

What about share links from Apple's apps?

Apple's own share buttons usually emit clean URLs (no fbclid / gclid / etc., since they're not Meta or Google's apps). But the link you copied into Apple's share path might already be dirty from wherever you got it. LinkClean cleans whatever ends up in your share-sheet payload, regardless of the source app.

If a link looks short, is it clean?

Not necessarily. URL shorteners (bit.ly, t.co, lnkd.in) hide the destination URL — including any tracking tail — behind a redirect. The expanded URL after the redirect is still dirty. LinkClean's E1 redirect unwrapping resolves these locally and runs the same cleaning pipeline on the destination.

Do all sites do this?

Tracking parameters are added by publishers, ad networks, and email tools — they're attached on the way out, not by the destination site. So they appear on any link served through a campaign, an ad, or an email — which is most of the high-traffic web. A direct link you typed into the address bar is usually clean.

Get LinkClean.

On-device URL cleaning for iPhone — from the share sheet, the app, Shortcuts, or a widget.