The address-bar URL is not automatically safe to forward
A marketer drops a landing page into Slack. Support pastes a complainant’s URL into Jira. An engineer copies a repro into a thread. In all three cases the cheapest move is the same: select the address bar, copy, paste. That bar shows the current document’s full URL. Under the WHATWG URL model it at least has a scheme, a host, a path, a query (after ?), and a fragment (after #). Fragments stay out of HTTP by default—that is the previous note. The query rides on the request line, and it rides on the clipboard too.
The query is often not required to open the page. You may have arrived from a tracked email, a paid click, or a social card that appended its own click token. The page only needs /product/42. The bar shows /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…. For analytics that is one attributable visit. For the next person who reads the string, it is a side profile that does not belong in a ticket: which campaign you came from, whether you just clicked an ad, whether a mail vendor numbered this recipient.
HTTPS only protects the hop against eavesdropping. It does not wipe the address bar, browser history, chat storage, screenshots, or access logs. OWASP’s note on information exposure through query strings is blunt: even on an encrypted channel, the query still shows up in Referer, web logs, shared systems, browser history, caches, and shoulder-surfing. The question before you share is not “is this site secure.” It is “does this question mark carry labels that should never leave this tab.”
UTM names a campaign. A click ID names this click.
Both kinds often sit on one URL. They do different jobs, and they leak different things. The first kind is a campaign label you (or the ad platform) wrote on purpose. Google Analytics Help calls them campaign parameters and gives the standard example: https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale. The docs say that if you add parameters, you should use utm_source, utm_medium, and utm_campaign together. Extensions include utm_id, utm_term, utm_content, and utm_source_platform. Values are case-sensitive: utm_source=google and utm_source=Google split into two rows in a report.
These labels usually do not encode a single person. They describe a channel and a campaign: which newsletter, which summer sale, the top link or the bottom one. Forwarding them into an external chat still leaks internal media structure. The recipient can read which campaign you are pushing and whether the click was email or paid, and they can guess your acquisition path from that. For a competitor or an unrelated third party, that is more than “open this page” requires.
The second kind is a click token the ad or mail platform appends on its own. Common names include Google Ads gclid, Display & Video 360 dclid, iOS-era gbraid / wbraid, Meta fbclid, Microsoft Ads msclkid, X twclid, and mail-vendor tokens such as mc_eid. Their job is to stitch “this click” back to the platform’s own records, not to give you a human sentence. The value is opaque to the recipient and readable to the platform. Forwarding a string that still has fbclid or gclid hands over a joinable click credential. Tokens like mc_eid sit closer to “this message went to this subscriber row.”
There is a third layer: the site’s own attribution or share parameters. Marketplaces and content sites often add spm, scm, pvid, share_token, or refer_share_id. Those are not Google’s UTM spec, but they still turn a “plain product page” into a trail of who shared it and from where. A strip policy that only deletes utm_* leaves this layer behind.
| Kind | Typical keys | Problem when you forward the URL |
|---|---|---|
| Campaign tags | utm_source, utm_medium, utm_campaign |
Leaks channel and campaign names the page does not need to open |
| Click / recipient IDs | gclid, fbclid, mc_eid, msclkid |
Can be joined back to one click or one subscriber record |
| On-site attribution | spm, pvid, share_token |
Carries a share path or referrer trail |
| Business parameters | id, q, sku, page |
Usually keep these; drop them and the page 404s or the result changes |
Where the query string lands after you paste
CWE-598—currently titled Use of HTTP Request With Sensitive Query String—states the defect as: sensitive data was placed in the query. It then shows up in browser history, travels to other sites via Referer, is written into web logs, or is copied into other records. The entry was renamed in the 4.20 release in April 2026 to stress that GET is not the only method that can carry a query: POST, PUT, and DELETE can too. The mitigation is specific: put sensitive data in the request body or in headers, not in the query string.
Most marketing parameters are not passwords or session tokens. The exposure surface is the same. Paste a full URL into instant messaging and you create at least these copies: the chat vendor’s message store, the recipient’s local history, and—if they forward it—the next hop’s store. If they open it, the destination’s access log records a request line that still has the parameters. If that page then loads a third-party script or image, the full URL can also ride in Referer toward an ad or analytics host. OWASP’s “shared systems” are ordinary inside a company: tickets, docs, error monitors, session replay. A link that was only meant for a repro becomes plaintext-searchable in those systems.
That is why “the site uses HTTPS” does not answer the forwarding question. HTTPS makes it harder for an on-path observer to read the plaintext. It does not stop you from pasting that plaintext into the next system. CWE-598’s real-world defects include a camera that put a password in the query and a comms product that put an access token on GET. Those are the same class of mistake, only worse. UTM and click IDs are usually milder. The mechanism is identical: whatever sits after the question mark is what people copy and what systems log.
Do not demo this with a live login, password-reset, or one-time-token URL. When you need to compare parameters, use a public product or docs page and append disposable test values, such as utm_campaign=canary-2026.
Referer can carry the query to a third party
Copy-paste is an active share. There is also a passive one: after the recipient opens the page, the browser’s default policy tells later requests “where I came from.” The header’s standard name is Referer (one r missing). MDN’s Referer privacy note uses a familiar example: a password-reset page with social links in the footer—click out and you may hand a token-bearing address to the social site. A third-party image on the page can send the current full URL to the image’s host the same way.
Browsers decide how much to send with Referrer-Policy. Chrome and similar engines default to strict-origin-when-cross-origin: same-origin requests may carry the full URL (path and query), a non-downgrade cross-origin request sends only the origin (scheme + host + port), and HTTPS-to-HTTP sends nothing. web.dev’s referrer guidance treats that default as a privacy-and-utility compromise. It blocks some “full query to another host” cases. It does not block same-origin analytics requests, and it does not help if the site sets unsafe-url or leaves the policy unset on an older client that still sends the full URL.
For “I only sent this to a coworker,” Referer still matters: once they click, the utm_* tags and click IDs you pasted may travel one more hop. If the landing page has a third-party pixel, a support widget, or a font on a CDN, and the policy allows a full URL, those parameters appear in those hosts’ logs. Stripping trackers from the query before you share cuts both hops: plaintext in the chat record, and a Referer that might fire after open.
The contrast with the fragment is worth one more sentence. A key after # is designed not to enter the request line, so it also stays out of ordinary Referer implementations. A query has no such layer. Campaign tags and click IDs sit after ? so servers and scripts can read them—which is exactly why they land in logs. To check “question mark enters the request, hash usually does not,” use the steps in Why a URL hash fragment is a fit place for a key—and when that protection fails.
The OS may strip some tokens. That is not a sharing policy.
Apple documents a built-in cut. On the Privacy Features page, Link Tracking Protection is stated as: when you share links in Messages, extra information some sites add to URLs is removed so those sites cannot track you or the person you shared with. Safari Private Browsing is described separately: link tracking protection removes tracking added to URLs as you browse. Apple publishes the capability, not a parameter roster.
There is no official full strip list. Community checks (PrivacyTests.org and similar) often mention gclid, fbclid, mc_eid, twclid, and dclid. Campaign tags such as utm_source usually remain. Coverage also has edges: regular Safari, a third-party browser, and an in-app WebView are not the same paths as Messages share or Private Browsing. A recipient on Android, in desktop Chrome, or opening from Slack or Teams will not strip for you.
So “my phone already removes tracking parameters” only means: on a specific system, in a specific app, some click IDs may be deleted before open. It does not mean: the string you pasted into Jira was already cleaned. Sharing happens at copy time, in a place the OS has not entered. What you control is the clipboard, not whether the other device will strip again.
What to strip, and what to keep
A rule you can run: ask first whether the page still opens without this key. A product id, a search q, a page number, a lang, or a query the document itself needs will change the resource if you drop it. Campaign tags, click IDs, mail-recipient numbers, and share tokens usually change attribution only, not the page.
The second question is what the link is for. A coworker reproducing a bug needs a stable resource address, not utm_campaign=summer-sale. A customer who should “open this product” needs sku, not the gclid from your last click. Keep UTM only when the task is “please enter through this tagged campaign so we can count this forward.” Even then, do not attach your own click ID.
Manual deletion misses keys. A live paid URL can carry five or six utm_* fields, one click ID, and two or three on-site tokens. Scanning right to left often deletes id and leaves fbclid. A stabler pass is by key name: drop every utm_ prefix; drop a known click-ID table; if the task allows, also drop common analytics keys (_ga, _gl, mc_eid, mkt_tok) and common commerce attribution. Keep path, host, and business query. Afterward, check the “removed keys” list—not only whether the result “looks shorter.”
Conservative and standard are two risk preferences, not two grades of anonymity. Conservative: touch only UTM and click IDs, leave unknown custom keys, so you do not delete a business parameter you have not seen. Standard: also drop common analytics and commerce attribution, which fits a link leaving the company or landing in a public space. Neither can claim “this is now anonymous.” A path can still contain a username. A query email= is not in the UTM table. Rule-based cleanup handles known tracker keys, not every sensitive field. Phone numbers, ID numbers, and keys in the message body need a separate redaction pass. Do not expect URL stripping to finish that job.
The shortest sentence worth sending a coworker: use path plus business parameters for a repro; use UTM for a count, and never attach your own click ID. If you are unsure, strip utm_* and *clid first, then read the remaining keys by hand.
Check it here: the strip list, then Network
“Local cleanup, nothing uploaded” is not self-proving. What you can see on the spot is three things: which keys were removed, which keys remain, and whether your original URL left as business data.
Build a canary first. Open a public page that does not involve a real customer, and append ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42. Paste the whole string into the cleaner. After it runs, the four tracker keys should be gone and id=42 should still be there. If the tool lists stripped names, check those names one by one. Do not stop at “the URL got shorter.”
Then open DevTools Network, enable Preserve log, and search the filter for canary-share or the full canary query. It should not appear on an XHR / Fetch request line, query, or body, and it should not appear in an analytics query or body. Static assets, styles, and scripts may appear—those are the page’s own files. Failure is the original string leaving as a business field. A title or path that says “privacy” or “clean” is expected. The full contents of the input box are not.
- Build a canary URL with
utm_*,fbclid, and a businessid. Do not use a real customer or a live campaign name. - After cleanup, check the table: tracker keys on the “removed” side,
idstill in the result URL. - Search Network for the canary string. A hit on any business request means the original left this tab.
The proof is narrow: in this run, known tracker keys disappeared by rule, the business key stayed, and the original did not leave this tab as an observed HTTP field. It does not prove an extension never read the input, and it does not prove a custom tracker outside the rule table was handled. After you change browsers or the rule list, run the canary again.
Practice the rules on a page that opens with no account
If you want a tool that prints the strip list on the page, start with MakePwd’s Privacy Cleaner. It opens with no sign-up and no account. URL parsing and parameter stripping happen in this tab. Per the product notes, the original string is not sent as a request and is not written to analytics. Standard mode removes utm_*, ad click IDs, common analytics parameters, and frequent marketplace attribution keys. Conservative mode removes only UTM and click IDs. The path and business parameters such as id and q stay. You can send up to 100 URLs at once. A single line over 8 KB is rejected. Only http or https is accepted.
Practice with the canary above, not a live click ID from a running campaign. After a run, look at two places: the strip list in the result pane, and Network for the original string. The list answers “did I delete the right keys.” Network answers “did it upload.” Both have to pass before you tell a coworker: these are the keys I removed, and I searched the canary with no outbound hit.
Cleanup only handles link shape. Phone numbers, national IDs, emails, and API keys in a chat or ticket body belong on the same page’s Data Redaction tool, masked by pattern, then rechecked by a person. MakePwd does not claim a GDPR or equivalent certification. If the cleaned result is still a secret that must not linger, send it once with Burn-Link and keep the key in the URL # fragment. For a whole file, use File Encryption Box on this device to make .lock / .enc, then send that over drive or mail. None of those steps requires a login.
FAQ
Will the recipient still reach the page after UTM is gone?
Yes, if the business parameters and the path remain. UTM and click IDs serve attribution, not routing. Drop utm_campaign or fbclid and the landing page should still open from the path and id. If you get a 404 or a different result, you hit a business key. Switch to Conservative and compare keys one by one.
Does HTTPS already protect these parameters?
Not at the moment you share. HTTPS lowers the risk of on-path eavesdropping. It does not wipe the address bar, history, chat, or logs. OWASP states that even on an encrypted channel, the query still appears in Referer, web logs, shared systems, and browser history. Whether you should paste the full URL is a different question from whether the site has a certificate.
Apple strips trackers. Do I still have to do it myself?
Yes. The system feature applies on documented paths such as sharing in Messages and browsing in Safari Private Browsing, and Apple does not publish a full key list. UTM usually stays. When you paste into a ticket or into chat on Android, those protections do not run for you. A sharing policy looks at the clipboard, not at whether the recipient’s OS will strip again.
Will a clean URL also drop the product id?
It should not, if the tool keys off names. id, q, and sku are not an utm_ prefix and are not on the common click-ID table. The check is a canary that holds both tracker keys and a business key, then confirms only the former disappeared. If a site writes tracking into a custom name, the rule table will not know it. Delete that key by hand or extend the list.
Three things to remember before the next share
First, selecting the whole address bar is not the same as “safe to send.” Split the query into campaign tags, click IDs, on-site attribution, and business parameters. Only the last kind should stay by default. Second, HTTPS and an OS auto-strip do not replace a clipboard check. The query lands in history, tickets, and logs, and it may travel again in Referer. Third, verify two places: the removed-key list, and a Network search for your canary.
If the next question is whether plaintext left this tab as business data, read How to verify browser encryption: prove plaintext never left. This note only turns “which query fields should not ride along when you share a full URL” into a range you can write into a conclusion.