Hold this first: what you strip before you share is the query that writes “where you clicked from” into the address. The check is not “the link got shorter.” Read the removed list, then confirm the pathname and id= / q= are still there. A cleaned URL is not a private visit, and it does not prove the landing page has no analytics script.
Answer the search intent in one sentence
You strip tracking parameters before you share a link because the query string is part of the HTTP request target. When the browser fetches the document, utm_source, fbclid, and gclid after the question mark are written into the request line. The host, any reverse proxy, and the access log are designed to see them. Paste the whole string into Slack or a ticket, and you hand the next opener the channel and the click mark as well.
This note is for support, ops, and anyone who wants to separate “what the address already writes” from “what still happens after the page loads” before they forward a URL. It is not a substitute for the privacy cleaner how-to, and it does not repeat which button produces a Clean Link. What you should take away is what UTM and click IDs each write, who inherits them when you share, what stripping can still prove, and how to compare the removed list with Network on this device.
The text after the question mark enters HTTP
RFC 3986 §3.4 defines the query as the segment after the first ? and before the fragment. RFC 9110 then states that the request’s target URI includes the path and the query, and excludes the fragment. A long address bar is not a cosmetic problem. This document request will hand the key–value pairs after the question mark to the other side.
The fragment after the hash stays in the current tab by default. An earlier note already covers how to check that. This one stays on the question mark. Keep both rules in view so you do not read “the server never sees the key after #” as “the server also never sees the channel after ?.”
The browser’s URLSearchParams API can split a query into pairs, delete them by name, and rebuild the address. A cleaner works at that layer: it edits a string. It does not disable scripts on the landing page. Deleting utm_campaign does not turn off the other site’s pixel.
UTM writes a channel, not a decorative suffix
Google Analytics describes manual tagging as a set of utm_* query parameters. The help article maps the common ones this way: utm_source to source, utm_medium to medium, utm_campaign to campaign name, plus utm_term, utm_content, utm_id, and newer fields such as utm_source_platform. The official example is http://www.example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summersale. That is the wording in the Analytics traffic-source note, not a guess.
Those values help the person who ran the campaign: the same article can be counted separately from email, a video description, and a Slack announcement. To the next person who opens the link, they are a plaintext note. A ticket that contains utm_source=vip_slack&utm_campaign=refund_202609 lets anyone who searches that ticket later read “this click came from that private campaign.”
UTM itself usually does not hold an ID number or a passphrase. What it leaks is context: which email you opened, which ad you clicked, whether you arrived through a support-only link. Once that context sits in a shareable URL, it no longer stays in your tab.
A click ID names one click, not a campaign
A click ID is closer to “this click” than to a campaign name. Google Ads auto-tagging appends gclid (Google Click Identifier) to the landing URL. The official shape is www.example.com/?gclid=123xyz. When auto-tagging is on and the site runs Analytics, that value can also be written into a first-party cookie so later conversions can be joined back to the click. See the Google Ads auto-tagging note.
In some iOS 14+ cases, gclid is not used without consent. Google introduced gbraid (web-to-app) and wbraid (app-to-web) so ad measurement can continue under those platform limits. That split is in the Analytics note on iOS 14+ campaign measurement, not a category a cleaner invented.
On the Meta side, the common name is fbclid. The developer docs state that if the page URL carries this query parameter, Conversions API can still build fbc from it. If the site runs Meta Pixel, the click id can also be written into a first-party cookie named _fbc, in the form version.subdomainIndex.creationTime.fbclid. The source is Meta’s fbp / fbc parameter note. Forward a URL that still has fbclid, and the colleague who opens it may still let the other site store “this click” in its own cookie and later events.
The same family shows up as msclkid, ttclid, twclid, and li_fat_id. Each one serves its own ad account. The shared fact is simpler: written in the query, it travels with the request line; written in the string you share, the next opener inherits it.
Do not experiment with a live campaign URL, a short link that embeds a customer phone number, or an unredacted ticket. Prepare a public sample and put one-time marks in the values. You are checking query and request lines—not spreading a real channel again.
When you share, the next person inherits the whole query
Share buttons, “Copy address,” and a long-press on a chat message usually copy the current full URL, not the short path the site would rather show in public. Slack, email, and ads previews make this obvious: you think you copied an article or a product, and the clipboard holds a pathname plus a trail of attribution fields.
Those fields then land in three places. First, the chat or ticket body, where everyone in the thread and anyone who searches later can read them. Second, the other person’s address bar, and any history that syncs from it. Third, the document request they send when they open it—the server log will contain the full query. Deleting the line from your own chat does not change people who already opened it, or logs already written.
Dropping a campaign monitor link into a public announcement, pasting a user’s long URL straight back into a ticket, and attaching a repro URL that still has gclid to an issue are the same action: you turned a click context that sat in your address bar into a mark anyone who can see those characters can reuse.
What stripping can prove, and what the address still holds
The claim a cleaned URL can support is narrow. Write it that way and you avoid one extra misread. It can prove that, on the list you used and in this run, known utm_* values, click IDs, and (in a wider mode) some attribution fields left the query. The pathname is still there. Business parameters such as id= and q= should stay by design. The link should still open the same article.
It cannot prove that the landing page has no pixel, that the other site has no first-party cookie, that a short-link hop will not add new parameters, that the path itself holds no tracking token, or that a browser extension did not rewrite the clipboard. It also cannot prove “nobody will know who you are after you open it.” You edited the string you are about to send. You did not edit the next browsing session.
Short links are the most common false pass. The shortener hides the real target behind its own redirect. Clean https://short.example/abc and the query is often empty, so the tool reports that it found nothing to strip. The tracking sits on the long URL after the 302. To check, open the short link in a private window and copy the final URL from the address bar. Do not use a short link that carries real private data for that step.
| What you see | What it can support | What it cannot support |
|---|---|---|
| The link got shorter | Some query characters are gone | You are already anonymous or already safe |
The removed list shows utm_* and fbclid |
Those keys left this URL | The landing page will not write _fbc or an Analytics cookie |
id= and q= are still there |
Business locators were kept by design | Every leftover key is required for the page |
| A short link reports “nothing to strip” | This short address itself did not match the list | The long URL after the redirect is also clean |
| Network does not show the original URL | This cleaning request did not send the source as business data | An extension or a chat client never stored it |
Compare now: the removed list and Network
A slogan is not evidence. Two checks you can finish on this device: one on the clean result, one on outbound traffic. Prepare a sample you can throw away, for example:
https://example.com/article/42?id=42&q=aes&utm_source=slack&utm_medium=social&utm_campaign=share_20260903&fbclid=IwAR0canaryfp&spm=demo.share.0
Put the canary in the utm_campaign and fbclid values. After cleaning, the clean address should no longer contain share_20260903 or IwAR0canaryfp. id=42 and q=aes should still be there.
- Read the removed-parameter list first. You should see
utm_source,utm_medium,utm_campaign, andfbclid. In a wider mode, an ecommerce attribution name such asspmshould appear as well. If the list is empty but the link “feels clean,” suspect a shortener or a mark in the path. - Then read the clean address’s pathname and leftover query. If the article id or the search term is gone, that is collateral damage. Do not share that result.
- Open DevTools Network, turn on Preserve log, and set the filter to All. Paste the canary into the search box. It should not appear in request lines, request bodies, or analytics payloads.
FastPwd’s Clean Link follows that boundary: parsing happens in the current tab; a single URL over 8 KB is rejected; a batch is capped at 100 lines; only http / https are accepted. Conservative mode removes utm_* and click IDs (including fbclid, gclid, gbraid, wbraid, and msclkid). Standard mode also removes _ga / _gl, mail tokens such as mc_eid / mc_cid, marketplace attribution such as spm / scm, prefixes such as _x_*, share tokens such as share_token, and—unless you keep them—ref / referrer. The pathname and id= / q= stay. The tool is ready to use; there is no account. Analytics records event names such as “cleaning ran,” not the source URL. A promise is still a promise. Trust what you see on this run in the list and in Network.
If you are not sure whether a key is a business parameter, switch to conservative mode. Get UTM and click IDs off the shared string first, then decide by hand whether spm or ref should stay. Keys the list will not touch, you delete with your eyes. Do not expect “it got shorter” to finish the job.
Three cases that look clean and were not stripped
First, the tracking sits in the path. Some share pages use /s/xxxx or a channel prefix in the path, and the query is empty. Deleting query keys by name barely changes the address. Compare the canonical URL after the hop, not the redirect shell the share button just emitted.
Second, the cleaner edits searchParams and leaves hash alone. If a tracker was written after the hash, query cleaning will report a pass. The check is still to put the full address-bar string next to the full result. Do not stop at the characters before the question mark.
Third, you cleaned the string you were about to send, and the chat client added parameters on the way out. Some clients stamp outbound links with their own click marks. After you send, open the message in another window and read the address bar again. Cleaning happens before paste. You still spot-check after send.
FAQ
After I remove UTM parameters, can the next person still be tracked?
Yes. You stripped the query on the string you are about to share. The landing page can still run pixels, first-party cookies, and a login session. Meta’s docs also note that even if the URL no longer has fbclid, a site that already wrote _fbc can still attach it to later events. Stripping only proves this URL lost known tracking parameters. It does not prove the next visit is anonymous.
Will a URL cleaner also delete an article id or a search query?
On a name-based list, the pathname and business query such as id= or q= should stay. If you are unsure, use conservative mode, which removes only utm_* and click IDs. After cleaning, read the removed-parameter list. Do not treat a shorter URL as proof. If a key you need appears on that list, discard this result.
Should I strip tracking parameters from a short link first?
A short URL often has no UTM of its own. The tracking sits on the long address after the redirect. Cleaning only the short form usually removes nothing. Open it in a private window, copy the final URL from the address bar, then strip that. Do not use a short link that carries real private data as a test. A public sample is enough.
When I clean a link on FastPwd, is the original URL uploaded?
Per the product notes, parsing and stripping finish in the current tab. The source URL is not sent as HTTP business data and is not written to analytics. Analytics records event names such as “cleaning ran.” To check this run, search Network for the canary: it should not appear in request lines, bodies, or analytics payloads. Localhost does not send analytics by default; repeat the check on the live hostname if you want a run closer to real use.
Compare the same link with a tool that is ready to use
If you want a page that writes the strip list in the open, open FastPwd’s privacy cleaner. No signup. Paste the sample above, run conservative mode, then standard mode, and compare the two “removed” chips. You should see both modes take UTM and fbclid; only standard mode should touch spm. In the clean result, id and q should still be there.
The same page can switch to text redaction for phone numbers and emails in a ticket body; that is a different article. When a whole secret must reach a coworker, use Burn-Link instead: encrypt locally with AES-256-GCM, store ciphertext only on the server, and keep the key after the hash in the link. Do not paste a just-cleaned business URL and a full Burn-Link into the same thread.
Before the next share, keep three facts. First, the question mark enters HTTP; channel and click IDs live there. Second, stripping only changes the string you are about to send; it does not shut off the landing page’s analytics. Third, short links, path marks, and parameters added after send each need their own check. An observation you can repeat is the one worth writing into your own outbound note.
Further reading
Do not mix the question mark with the hash. Why a key can sit after #, and which layer dies when you paste the full link into chat, is in Why a URL hash can hold a key, and when that protection fails. How to compare phones, ID numbers, and API keys in a ticket before they leave this machine is in Before you paste tickets and logs into AI, check which fields leave this machine. To confirm the cleaner itself did not send the original URL as business data, use the canary steps in How to check if browser encryption never uploaded plaintext.