A URL has a path and a query string. The path names a resource. The query string, everything after the question mark, was designed to pass parameters to the server: a search term, a page number, a language preference. Link decoration is the practice of stuffing that query string with identifiers whose only job is to recognize you on the other side of the click.
You have seen the common ones. utm_source, utm_medium, and utm_campaign describe where a link came from. fbclid is a Facebook click identifier. gclid is a Google one. These look like attribution housekeeping, and at the low end they are. The privacy problem appears when the decorated value is specific enough to single out one person, and when two parties on opposite sides of the link can join their records on it.
Why It Works When Cookies Do Not
Browsers have spent years walling off cross-site cookies. Storage is partitioned by site, third-party cookies are blocked or isolated, and a tracker on site A can no longer simply read the cookie it set on site B. Link decoration routes around all of that, because the identifier does not live in storage. It lives in the link itself.
The mechanism is a bounce. You are on site A. You click a link that takes you to a tracker domain, which immediately redirects you to site B, passing a decorated identifier along the way. The tracker sees you on the way through, reads its own first-party cookie at that moment, and writes the matching identifier into the URL it forwards to B. Now B receives an identifier the tracker can later reconcile. No cross-site cookie was ever read. This pattern has a name in browser-engineering circles: bounce tracking, or navigational tracking.
A single tracking parameter is inert on its own. It becomes identifying when the sender and the receiver can both map it back to the same person. Link decoration is a courier for that shared key. Stripping the parameter breaks the join even when both parties keep their own records.
Where the Identifiers End Up
A decorated URL is unusually leaky because URLs travel further than cookies do. Once an identifier is in the query string, it can show up in:
- Server access logs on the destination site, retained for as long as logs are kept.
- The Referer header sent to resources the destination page loads, unless a strict referrer policy trims it.
- Browser history and synced history across your devices.
- Anything you paste the link into: a chat message, an email, a bookmark, a shared document. The identifier rides along, now attached to whoever you sent it to.
That last case is the quiet one. When you share a decorated link with a friend, you can hand a tracker a link between your two identities that neither of you intended to create.
What Browsers Now Strip
Browser engines have started treating known decoration parameters as removable. The approaches differ in how aggressive they are:
| Browser | Behavior |
|---|---|
| Firefox | Query Parameter Stripping removes a maintained list of known tracking parameters from links during navigation and when you copy a link, active in strict tracking protection and in private windows. |
| Brave | Strips known parameters by default and runs debouncing, which collapses tracker bounce redirects so you skip the intermediate hop entirely. |
| Safari | Removes known tracking parameters from links in private browsing and limits the lifetime of identifiers set through bounce navigations. |
These defenses are list-based, which means they catch the well-known parameters and miss novel or site-specific ones. They are a meaningful reduction, not a guarantee. A parameter the maintainers have not catalogued passes through untouched.
What You Can Do
A few habits close most of the gap:
- Strip before you share. When you copy a link to send to someone, delete everything from the question mark onward unless you know a parameter is needed for the page to load. Most articles render fine with a bare path.
- Use a cleaner. Tools like ClearURLs apply community-maintained rules to remove tracking parameters automatically, going beyond the built-in browser lists.
- Turn on strict tracking protection in a browser that does parameter stripping and bounce-tracking mitigation, and prefer one that debounces redirects.
- Set a tight referrer policy where you control the site, so decorated URLs do not leak onward through the Referer header.
The Same Logic, Other Channels
Link decoration is one instance of a recurring move: when one tracking channel closes, identity migrates to whatever channel is still open. Cookies got partitioned, so identifiers moved into URLs. URLs get stripped, so some trackers move to CNAME cloaking at the DNS layer or to server-side joins you never see. The countermeasure is rarely a single setting. It is treating links, like cookies and DNS, as a surface where identity can hide.
This is also why the cleanest communication tools carry no decoration of their own. When you send someone a message, the link should be the link. We do not append identifiers to outbound URLs, and an encrypted message body is not a place a third party can quietly insert one. The absence of a tracking payload is a property you can verify, not a promise you have to take on faith.