Support pastes a campaign page into a ticket. Marketing drops a product URL into Slack. A developer shares a docs link in chat. Those three moves happen every day, and the string that lands in the next person’s clipboard is often longer than anyone intended: utm_source=newsletter, a fifty-character fbclid=, a dotted position code such as spm=. Forward the whole thing and you also forward the campaign channel, the ad-click identity, and the slot that produced the click.

The opposite habit is just as common: wipe everything after the question mark “to be safe.” YouTube then 404s, a storefront returns to the homepage, and a search page becomes an empty list. The question is not whether to clean a URL. It is how to split two kinds of query names: tracking labels you can strip, and resource locators you must keep. The table, exceptions, and checks below stay on that one decision. MyPassGen’s Clean URL page follows the same split; this article is not a tool tour. It answers which parameters to delete when you share a link, and which ones to leave alone.

Not everything after the question mark is junk

The part of a URL after ? is the query string. Per the WHATWG URL Standard, when you open an http or https link the query is sent on the request line and typically lands in the destination site’s access logs. That is a different object from the fragment after #. Browsers do not include the fragment in the HTTP request by default. The query does go out.

A query is a list of name=value pairs joined by &. The browser’s URLSearchParams API lets you read and delete names without hunting for question marks by hand. Whether a pair is safe to strip depends on the name — whether the page needs it to locate content — not on how long or random the value looks.

Tracking parameters: labels for analytics

Tracking parameters exist for statistics, ad attribution, and mail systems. The page template usually renders the same article or product without them. After you delete them, the visitor should still land on the same content. What changes is the destination’s report: it records one fewer “this click came from that ad or that email.”

Google Analytics writes those labels as UTM parameters. The help article Collect campaign data with custom URLs lists utm_source, utm_medium, utm_campaign, utm_term, utm_content, and utm_id. Source, medium, and campaign are the three Google says you should always include on a custom campaign — for the marketer who tagged the URL, not as a requirement for the page to load.

Business parameters: what opens this exact resource

Business parameters point at a specific resource. YouTube’s v= is the video ID. A store’s sku=, id=, or Shopify variant= selects one SKU. A search page’s q= is the query. Pagination’s page= decides which screen you meant to share. Delete those names and the server does not know which object you wanted. You get a 404, a homepage, or an empty result. A short name or a value that looks like noise is not proof that the pair is tracking.

Ask one question before you delete

Does this name tell an analytics system where the click came from, or tell the server which record to open? If you cannot answer, start with names that begin with utm_ and the common click IDs, then open a new tab and check that the title and body are still the same page.

Tracking parameters you can usually strip

The table below is grouped by source. It is not a complete catalog — ad platforms invent new names — but it covers the pairs that most often ride along when you copy from an ads console, a newsletter, or a share button. Removing them rarely changes the page you meant to open.

Group Common names What usually happens after you strip them
UTM campaign tags utm_source utm_medium utm_campaign utm_term utm_content utm_id Same page; the destination loses one campaign attribution
Ad click IDs fbclid gclid gbraid wbraid msclkid dclid twclid Same page; the ad platform loses one click match
Analytics and email _ga _gl mc_eid mkt_tok Same page; one fewer cross-domain or mailbox identity stitch
Marketplace attribution spm scm pvid utparam share_token Most product pages still open; slot codes and share tokens stop traveling

fbclid is the click identifier Meta products attach after a share or ad hop. gclid is Google Ads’ click ID. msclkid belongs to Microsoft Advertising. gbraid and wbraid show up on Google’s attribution path after third-party cookies were restricted. The values are long and look like secrets. Their job is still attribution, not locating an article or a SKU.

Safari’s Link Tracking Protection, shipped with iOS 17 and tightened in later releases, already strips a community-reported list of click IDs in Mail, Messages, and Safari Private Browsing. Apple does not publish an official list. Reports consistently include gclid, fbclid, and msclkid. Standard UTM names are not on those reported lists, which is why a URL pasted out of iOS Messages may already be missing the click ID and still carry utm_source. That is useful context, not a reason to stop cleaning before you forward. Your colleague on Chrome still receives whatever you left on the string.

Marketplace codes such as spm (a super-position model used on several large retail sites) mark which slot produced the click. If you forward that name together with the product ID, the destination may credit your slot — and your ticket or Slack thread now contains a map of their placement structure. Keep the product ID. The slot code can usually go.

A grey set of names remains: ref, source, from, and Amazon-style tag=. Some sites use them only for campaign credit. Others switch templates or affiliate payouts based on the value. If you are unsure, leave them, strip only UTM and click IDs, then compare title, body, and product options in a new tab.

IDs that break the page if you delete them

Business parameters have no shared prefix. You recognize them by what the site does with the name. These groups almost always have to stay:

  • Resource IDs: v= (video), id= / sku= / pid= / variant= (product or object), doc= (document number).
  • The query itself: q=, query=, keyword= on search pages; coordinates or a place ID on a map.
  • Paging and sort: page=, p=, offset=, sort=. Deleting them often returns page one or the default order. That is not always a 404, but it is no longer the screen you meant to share.
  • Language and site: hl=, lang=, locale=. Removing them can jump you out of the language version you were checking.

A test you can run immediately: copy the full query into a notes app, delete one name, and open the result in a private window. If the title, hero image, price, or body no longer matches, put that name back on the “must keep” side. Do not clear the entire query and then guess which pair broke the page.

Links that carry a login or one-time token are a worse case. token=, auth=, and access_key= also look like random strings, but they may be a session or a download credential. Those values are not UTM tags, and they should not appear in a group chat. Do not forward a URL that contains a token. If someone else needs the same content, send them through their own sign-in, or encrypt the file on this device and pick another channel.

Do not paste the full query into an unknown “online cleaner”

A query string can mix session tokens, preview codes, and internal object IDs. Pasting the complete URL into a site that uploads the original writes those values into someone else’s logs. Cleaning should stay in the current browser tab and list the names that were removed, so you can check — not ask you to trust a “we do not store this” line.

Short links, QR codes, and copy buttons hide the query

A bit.ly, t.co, or amzn.to address is not proof that the query is clean. A short link is one hop: the browser requests the short host, then follows a 301 or 302 to a long URL that still holds the full query. What you copied in chat is the short piece. After the recipient clicks, the address bar can still show utm_ names and click IDs.

QR codes work the same way. Many share buttons first build a long URL with tracking parameters, then compress it into a code. After a phone scan, read the address bar after the redirect, not the image on the poster. To share a clean link, copy from the landed address bar. Do not forward the “copy short link” control from a campaign console.

Email and SMS wrappers are easier to miss. Some mail providers rewrite every href onto their own click-tracking host, then bounce to a destination that still carries mkt_tok or mc_eid. The URL you want to forward is the final landing page, not the tracking hop inside the message. The order is: open it yourself, wait until the address bar stops changing, then decide which query names to delete.

Verify on the spot: address bar, new tab, Network

Slogans cannot be checked. Traffic can. These steps do not depend on a brand promise. The browser will show the result.

  1. Paste the full URL into a notes app, including the original query, so you are not editing from memory.
  2. Using the table above, delete only utm_* and click IDs (fbclid, gclid, and the rest). Leave business IDs alone for this pass.
  3. Open the cleaned address in a private window or a new tab. Compare title, body, price, or video. It should still be the same object.
  4. Open DevTools → Network, enable “Preserve log,” and reload. Look at the document request’s Request URL: stripped names should be gone; v= and id= should still be present.
  5. If the page is wrong, put back the name you just removed. Restore one name at a time until you find the pair the page actually needs.

If you use a tool that lists “names that were removed” in the browser, read that list against the Network Request URL. A name on the list that is absent from the request is actually gone. A name you deleted by hand that never appeared on the list — especially id= — is collateral damage. Put it back.

MyPassGen’s Clean URL page works on that boundary. Standard mode covers common UTM values, click IDs, and some marketplace attribution names. Conservative mode mainly touches UTM and click IDs. Stripping runs in the current tab. The original is not uploaded, and you do not create an account. The page lists the parameters it removed so you can compare them with the address bar. A single URL over 8 KB, or a paste of more than about 100 lines, should be split. Do not assume the tool will swallow an arbitrary blob of text.

Mistakes: wipe the query, trust the short link, ignore tokens

“Everything after the question mark is junk” is the most common over-clean. Search terms, paging, language, and resource IDs all live in the query. The safe default is a whitelist delete (only known tracking names), not a blacklist wipe (delete every unknown name).

“The short link is already short, so it must be clean” does not hold. Shortness is the redirect layer, not the landing query. To verify, you have to see the address bar after the hop finishes.

“HTTPS already protects privacy” only covers eavesdroppers on the path. When the recipient opens the link, the destination still sees the full query. What you are reducing is unnecessary labels on the copy you send. That is not HTTPS’s job.

“Cleaning a link is the same as redacting text” is also wrong. Phone numbers, national IDs, email addresses, and API keys usually sit in the body, a screenshot, or a ticket table — not in the URL. After the link is clean, those fields still need a local mask. Removing utm_ is not the end of the pass.

Where to start cleaning

Start with the one URL you are about to send today. Open the original, wait for the address bar to settle, copy the full string, strip only UTM and click IDs from the table, verify in a new tab, then send it. Old links in a Slack topic, a knowledge base, or a ticket template can wait. You do not need to clean the whole site in one sitting.

If one paste contains several URLs, split them by line and read the names after each question mark. When a single address has both id= and spm=, keep id=, drop spm=, then open it and confirm the product did not change. After that one pass you can already answer the title question: tracking labels can go; business parameters that locate the content cannot.

If the cleaned address still travels with a secret, do not put the key back into the query. A one-time short secret belongs on a one-time link, with the key after # in the URL. A file you may need to decrypt again belongs in the file encryption box, which builds a .lock / .enc file on this device. Link cleaning reduces labels on a forward. It is not a key-exchange channel.

FAQ

After I remove UTM parameters, does the other person still get the same page?

On most content sites and product pages, yes. UTM tags feed campaign reports. The template usually does not need them to render the body. Trust the title and main content in a new tab, not only an HTTP 200.

fbclid is long. Is it a secret? Can I forward it?

It is a click identifier, not a login password — and there is still no reason to send it on. Leaving it hands the next opener the attribution chain for that click, and writes it into whatever chat log they keep.

Should I expand a short link before I strip parameters?

Yes. Open the short link in your own browser, wait for the redirect to finish, copy the long URL from the address bar, then delete tracking names from the table. If you only forward the short form, the recipient can still land with the full query.

Do I need an account to clean a URL? Is the original uploaded?

No account. The log risk starts when you hand the URL to a site that uploads the original. Local processing keeps the original in the current tab. What you check is whether Network sent the full URL to a third party, and whether the names on the removal list actually disappeared from the address bar.