fbclid, gclid and msclkid are click IDs added to links. What they record, why cookie blocking misses them, and what Safari and Brave strip.
You click a link in a feed, and the page that opens has a long tail on its address: ?fbclid=IwAR…, or ?gclid=Cj0K…. You never typed it, and the page looks the same without it. So what is it, and is it tracking you? Short answer: yes, that is its job. This guide explains what these click IDs are, why they work even when cookies are blocked, what browsers do about them, and when it is safe to delete them.
Key Takeaways
fbclid,gclidandmsclkidare click identifiers. They are added to a link by Meta (Facebook), Google Ads and Microsoft Ads respectively, so the platform can connect a visit on another site back to the click that caused it.- They differ from
utm_tags. Autm_campaign=springtag is the same for everyone who clicked that campaign. A click ID is tied to one click, which is why privacy features such as Brave's filter treat the two differently. - They live in the URL, not in storage. Third-party cookie blocking and storage partitioning do not touch an identifier that travels in the address itself.
- Some browsers now strip them. Brave removes listed click IDs from cross-site requests; Safari blocks known tracking query parameters in Private Browsing and limits what known fingerprinting scripts can read from the URL.
- Deleting one before sharing a link is usually harmless, but not guaranteed to be: some sites keep real state in the query string.
What a Click ID Is
When you click an ad, or a link shared inside a platform, the platform can rewrite the destination so it carries a random-looking token:
| Parameter | Added by | What it stands for |
|---|---|---|
fbclid | Meta (Facebook) | Facebook Click Identifier |
gclid | Google Ads | Google Click Identifier |
msclkid | Microsoft Advertising | Microsoft's equivalent of gclid |
The token reaches the destination in two ways at once: the destination's server receives it as part of the page request, and the page's analytics or advertising script can read it from the address and send it back to the platform. The platform can then match that visit to the original click and, if you were signed in there, potentially to your account. That is how an advertiser learns that this click produced that purchase. Brave's privacy team describes the same chain in its write-up on query stripping: these values are added to URLs you click so that advertisers can learn more about you and your behavior on the web.
The general technique is called link decoration: a tracker adds an identifying query parameter to a link as you leave one site and reads it back out when you land on another, which lets it connect your behavior across two independent sites. It is also the carrier in the redirect variant covered in bounce tracking explained, so we will not repeat that mechanism here.
Click IDs vs Campaign Tags
Not every parameter is personal, and that distinction shapes what gets stripped:
- Campaign tags (
utm_source,utm_medium,utm_campaign) describe where a visitor came from. Everyone who clicked the same newsletter link carries the same values. They answer "which campaign worked?" without singling anyone out. - Click IDs describe one click. If the value is unique, it can be joined to whatever the platform already knows about the person who made it.
Brave's Query String Filter states this design directly: it targets parameters known to be specific to a user, an email address or an individual click, without interfering with coarse-grained campaign-level tracking.
Why Cookie Blocking Does Not Stop Them
Third-party cookie blocking and storage partitioning both restrict what an embedded third party can store and read back across sites. A click ID never needs to be stored by a third party at all. It rides inside the navigation, the destination's server and its own script (a first-party context) both see it, and the page forwards it to the platform. To the browser, that is an ordinary first-party script making an ordinary request.
Clearing cookies afterwards does not undo this either. The ID was attached at click time and has already been delivered, and a clean profile that clicks the same ad simply receives a fresh one. That is why browsers have to treat the URL itself as the thing to clean.
What Browsers Do About It
Each of these is narrower than "blocks all tracking", so read the scope carefully.
Brave. The Query String Filter removes listed parameters (name and value) before a non-same-site GET request proceeds, covering navigations, subresources and redirects. The parameter therefore never reaches the server, the address bar or the Referer header, and cannot be recovered by scripts on the page. There is a stated exception: where a user-identifying parameter is required for an email unsubscribe link to work, Brave leaves it in place. Brave's 2020 write-up, linked above, names fbclid, gclid and msclkid as examples of what it strips.
Safari. WebKit's notes for Safari 17.0 list blocking for known tracking query parameters in links among the added protections in Private Browsing. Separately, WebKit's Safari 26.0 notes say Safari prevents known fingerprinting scripts from reading state that could be used for navigational tracking, such as query parameters and document.referrer. In normal browsing, Safari's Intelligent Tracking Prevention also caps the expiry of cookies that script creates on a landing page it detects as link-decorated to 24 hours; the details are in Safari ITP, mechanism by mechanism.
Firefox. Mozilla's anti-tracking policy classes URL decoration as navigational cross-site tracking and says Firefox "will seek to identify query parameters that sites use for tracking purposes" and remove them from cross-site, top-level navigations. It makes an exception for attribution that is not user-specific. That is a statement of policy, not a list of parameters or a promise about your settings, so do not read it as a guarantee for any one of these three.
Chrome and other Chromium browsers. We have not verified a first-party statement to cite, so we make no claim here. The practical check for any browser is simple: click a link that carries one of these parameters and see whether it is still in the address bar when the page opens.
The Referer Header Carries a Similar Risk
The address of the page you just left is also sent to the next site in the Referer header. If that address contains a click ID, the ID could travel one hop further. Browsers now default to a trimmed value: MDN documents that, with no policy set, the default is strict-origin-when-cross-origin, which sends only the origin on cross-origin HTTPS requests and no header at all from HTTPS to HTTP. See MDN's Referrer-Policy reference for the full list of policies. Safari goes further and downgrades all third-party referrers to their origin, as the ITP guide linked above explains.
Should You Delete the Parameter?
For sharing a link, usually yes. When the part before the ? is a plain article or product address, you can delete everything from the ? onward and the page normally loads identically. If the address has other parameters too, the safer edit is to remove only the fbclid=… part (or gclid=…, msclkid=…) and leave the rest. Either way, the person you send it to will not arrive carrying the ID from your click, and the link gets shorter.
Two cautions. Some applications keep real state in the query string (a search term, a page number, a session or invite token), and stripping it would change or break the page, so open the cleaned link once before sending it. And deleting the parameter does nothing about the click that already happened: the platform saw that when you clicked. We do not recommend a specific extension or tool here; use your browser's built-in protection if it has one.
What a Stripped URL Still Leaves Behind
Removing the click ID removes one explicit identifier. A site can still recognize you without being handed one, from the combination of attributes your browser exposes. That is browser fingerprinting. It is why persistent visitor IDs survive cookie clearing, and why the browser fingerprinting guide matters alongside URL cleanup.
To be precise about what BrowserInsight does: our tools do not inspect the links you click or the URLs you visit. Our fingerprint check runs entirely in your browser and shows what a site could read about it, which is the layer a URL-stripping feature cannot remove.
Frequently Asked Questions
Is fbclid a virus or a sign my account was hacked?
No. It is plain text in the address, and it does not run anything on your device. Seeing it only means the link passed through a platform that adds click IDs. The concern is privacy, not malware.
What does gclid mean?
It stands for Google Click Identifier. It does the same job for Google Ads that fbclid does for Meta and msclkid does for Microsoft Advertising.
Does a VPN or a private window remove click IDs?
A VPN changes your IP address, not the link, so the ID still arrives. A private window does not change the link by itself either. Safari's Private Browsing, described above, is a specific protection rather than something every browser's private mode is documented to do.
Conclusion
fbclid, gclid and msclkid are one-click identifiers written into the link itself, which is why they sidestep cookie and storage defenses. Some browsers are closing the gap by cleaning the URL, but coverage differs by browser and mode. Removing them from links you share is a sensible habit; just remember that the URL is only one of several places an identifier can come from.
Recommended Reading:
