SafeShare Help

Link Cleaning Rules

Transparent and reproducible: what gets removed, what stays, and why (with reason codes).

Open App Standard vs Strict Domain overrides Changelog
Reality check: SafeShare removes tracking ballast in URLs. It does not promise “invisibility on the web.”

Contents

  1. Standard vs Strict (decision goal)
  2. Reason codes (what they mean)
  3. 1) Always remove (Standard + Strict)
  4. 2) Usually kept in Standard (stability)
  5. 3) Additionally removed in Strict
  6. 4) Domain overrides
  7. Examples (before/after)
  8. Clear scope
  9. FAQ

Standard vs Strict

Standard (recommended)

  • Removes known tracking parameters.
  • Prioritizes destination stability (search, filters, language, IDs still work).
  • Best default for everyday sharing.

Strict (more aggressive)

  • Removes additional context hints (strict-extra).
  • May change destination behavior (e.g., Amazon listings, referral flows).
  • Use when you accept possible behavioral changes.

Important: Sometimes both modes produce the same output. Differences appear only when strict-extra rules apply.

Reason codes (meaning)

SafeShare doesn’t decide “magically.” Each parameter is removed or kept with a reason code (visible in the app’s transparency output, if enabled).

Removal reasons

  • tracking_rule — removed by a known tracking rule
  • strict_extra — removed only in Strict mode

Keep reasons

  • stability_keep — kept to preserve destination behavior
  • domain_strict_keep — kept in Strict due to domain-specific rules
  • not_flagged — no tracking hint detected
How to read this: “keep” does not mean “safe” — it means “functionally important or not flagged.”

1) Always remove (Standard + Strict)

Typical tracking parameters removed in both modes.

Exact keys

fbclid, gclid, dclid, msclkid, ttclid, twclid, li_fat_id, epik, yclid,
mc_cid, mc_eid, _hsenc, _hsmi, mkt_tok, vero_id, vero_conv, wickedid,
rb_clickid, s_cid, zanpid, cmpid, igshid, gbraid, wbraid, oly_anon_id, oly_enc_id

Prefix rules

utm_, pk_, mtm_, hsa_, icn_, ici_, oly_, vero_

These parameters are commonly used for attribution, ad click IDs, email campaign tracking, or cross-site measurement.

2) Usually kept in Standard (destination stability)

Many parameters are functional: they control search terms, language, filters, product variants, or page state. Standard mode typically keeps these to avoid breaking the destination experience. 

q, query, search, s, p, page, lang, locale, v, t, id, story, article, item,
post, video, playlist, list, sku, variant, color, size, sort, filter, kgmid, tbm, uule,
ref, si, spm, sr, qid
Key idea: Standard is designed to be “safe by default” for normal sharing: fewer surprises on the destination.

3) Additionally removed in Strict

These keys are often used as referral/context hints. Strict mode removes them to reduce link-borne context — at the cost of potentially changing behavior. 

ref, si, spm, sr, qid, source, from, via

If Strict changes the destination in a way you don’t want: switch back to Standard.

4) Domain overrides

Some domains use parameters in a way that affects functionality (video IDs, search state, lists). Overrides keep essential keys even in Strict.

YouTube

  • Standard keep: v, t, list, si
  • Strict keep: v, t, list (without si)

Google

  • Standard keep: q, tbm, kgmid, uule
  • Strict keep: q, tbm, kgmid, uule

Amazon

  • Standard keep: k, keywords, qid, sr, ref
  • Strict keep: k, keywords (without qid, sr, ref)

Examples (before/after)

Three quick examples showing why Standard and Strict can differ.

Example 1 — YouTube: Strict removes si 
Input:
https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=43s&list=PL123&si=ABCD&utm_source=x

Standard:
https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=43s&list=PL123&si=ABCD
Removed: utm_source(tracking_rule)
Kept: v,t,list,si(stability_keep)

Strict:
https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=43s&list=PL123
Removed: utm_source(tracking_rule), si(strict_extra)
Example 2 — Amazon: Strict removes qid/sr/ref 
Input:
https://www.amazon.de/s?k=usb+cable&qid=1700000000&sr=8-3&ref=sr_1_3&utm_medium=email

Standard:
https://www.amazon.de/s?k=usb+cable&qid=1700000000&sr=8-3&ref=sr_1_3
Removed: utm_medium(tracking_rule)
Kept: qid,sr,ref(stability_keep)

Strict:
https://www.amazon.de/s?k=usb+cable
Removed: utm_medium(tracking_rule), qid/sr/ref(strict_extra)
Example 3 — Newsletter tracking: both modes identical 
Input:
https://example.com/article?mc_cid=111&_hsenc=p2ANqtz&mkt_tok=abc123&utm_campaign=spring&id=42

Standard:
https://example.com/article?id=42
Removed: mc_cid/_hsenc/mkt_tok/utm_campaign(tracking_rule)
Kept: id(stability_keep)

Strict:
https://example.com/article?id=42
Removed: mc_cid/_hsenc/mkt_tok/utm_campaign(tracking_rule)
Kept: id(not_flagged)
Try a real link See QA baselines

Clear scope

Clean a link now Open Help Center See SafeShare Pro

FAQ

What is the difference between Standard and Strict mode?

Standard removes known tracking parameters and prioritizes stable destination behavior. Strict removes additional context hints and can change behavior.

Does SafeShare remove all tracking?

No. SafeShare focuses on URL parameters. It does not block IP logs, fingerprinting, or tracking after login.

Why are some parameters kept?

Because many parameters are functional (search, language, filters, IDs). Standard keeps them to avoid breaking the destination experience.

When should I use Strict?

When you explicitly want stronger cleanup and accept potential changes. For everyday sharing, Standard is usually the better default.

Contact

If a real-world link behaves unexpectedly, send us the link (without sensitive data) and we’ll help you quickly.

Send email Open changelog