Removing URL Parameters

This is a basic guide to removing URL parameters using uBlock Origin by creating static filter rules.

Q: What are URL parameters?

A: They are parameters with values appended after the URL, usually for analytic and tracking purposes.

Example (everything past the TLD and subsequent forward slash):

  1. Install uBlock Origin on a compatible browser, such as Firefox ESR. The rest of this guide will assume you are doing exactly this.

  2. Go to about:addons, and access the preferences of uBlock Origin.

  3. Access the “My Filters” tab, and in the text box, add static filter rules, such as these examples:

  1. Test your settings against a real URL, like this one (courtesy of @david.hamner):

After accessing it with these static filter rules, the URL should be free of Matomo Campaign Tracking URL parameters.

If you want to continue testing on more websites that track you more aggressively, I suggest moving to Rob Braxman’s website next, who claims to be committed to perserving your privacy.

Here are my static filter rules for Rob Braxman. Note that adding additional static filter rules after this may break their store:


A nastier example I have after this is TELUS, a “local” ISP in Western Canada.

Here are my static filter rules for TELUS:


One last example I will do is eBay, which I personally use often due to guest checkout.

Here are my static filter rules for eBay:


Great post!

You can also specify regular expressions to match on a pattern so that you don’t have to play the whack-a-mole game on all the possible analytic query parameters.

See the uBlock documentation for more information: Static filter syntax · gorhill/uBlock Wiki · GitHub

The value assigned to removeparam can be a literal regular expression, in which case uBO will remove query parameters matching the regular expression:


The above filter will remove all query parameters whose name starts with utm_, regardless of their value. When using a literal regular expression, it gets tested against each query parameter name-value pair assembled into a single string as name=value.


Yes, that should simplify Matomo Campaign Tracking and Urchin Tracking Module URL parameters, but it will not be very effective against eBay’s free-for-fall approach.

So in this case, these are the simplified static filter rules:


For eBay, they have a few URL parameters that can be targeted with this strategy:


Here are more efficient methods to filter URL parameters, but they may break website functionality. A more detailed explanation of these can be read from AdGuard.

If you want to block all URL tracking parameters for one specific website, such as TELUS, add this static filter rule:


If you want to whitelist one parameter on eBay but remove everything else, use this instead:


If you just want to block all URL parameters, period:


Just throwing an idea out there but maybe one could remove all URL parameters except for whitelisted domains with legitimate parameters i.e. where the domain does actually support some kind of lookup or query via GET parameters (query string) and you trust the domain and you know what the legitimate parameters of that query are.


See my post above yours for a static filter rule with eBay showcasing that exact situation. Also, if you are interested in the nitty gritty details of how most of eBay’s tracking URL parameters work, see these two articles below.


Indeed, much like the recommended method for input sanitation is to use an allowlist rather than a blocklist, I think the same should apply here if there is concern from any person.

It is a common mistake to use block list validation in order to try to detect possibly dangerous characters and patterns like the apostrophe ' character, the string 1=1, or the <script> tag, but this is a massively flawed approach as it is trivial for an attacker to bypass such filters.
Allow list validation is appropriate for all input fields provided by the user. Allow list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized.

1 Like

Here is a further manual refinement of eBay’s static filter rules, which now uses regular expression:


As for an explanation of the whitelisted URL parameters listed so far:

  • _nkw - Search
  • _pgn - Page Number
  • _sop - Sort Order Page
  • blrs - Best Listings Results
  • ipg - Items Per Page
1 Like

When will people learn that security through obscurity is meaningless? :joy:

Awesome find. Mind sharing the filters as an export from the addon when you feel you have a fairly robust list?

1 Like

Well my strict security practices already presanitize my web browsing experience: I only have Matomo Campaign Tracking; Urchin Tracking Module; and eBay as justified entries for URL parameters. Even then, it is clear that the way I use eBay is pretty limited already, and that I do not use all of the available search filters; what I use right now is enough for my needs, but may be subject to change in the future.

1 Like

Here is another manual refinement of eBay’s static filter rules.


New URL parameters and their functions:

  • action - Action, used with the value “create” during the “Buy It Now → Check out as guest” process; bypasses the other URL parameters and processes mentioned below
  • cartid - Cart ID, used during the “Go to checkout → Continue as guest” process
  • guestCheckoutEligible - The value “true” is used to authorize the “Go to checkout → Continue as guest” process
  • item - Item ID, used during the “Add to cart” process
  • srt - ? (maybe something like “Seller Reference Tracker”), required along with the item URL parameter during the “Add to cart” process

This will allow you to buy the item(s) immediately or to add items to your cart for checkout. I have not had any justification to purchase anything from eBay yet to confirm and verify that the entire checkout process works, but I will do so when an opportunity occurs later in the future.

1 Like

The eBay checkout process works with these static filter rules, although the URL states the transaction has succeeded while the HTML content itself states there is an error. I have received a confirmation email nonetheless, but I may continue to add more whitelisted URL parameters in the future for a more pleasant shopping experience as well as to reassure confidence with the entire process.

Here is my updated eBay static filter rules:



  • _dmd - Allows listings to change between List and Grid View.
  • LH_ALL - Left Hand All, presents all listings.
  • LH_Auction - Left Hand Auction, presents all auction listings.
  • LH_BIN - Left Hand Buy It Now, presents all Buy It Now listings.
  • LH_ItemCondition - Left Hand Item Condition, presents specified item conditions (New, Used, Not Specified, etc.)
  • LH_PrefLoc - Left Hand Preferred Location, presents listings specified by country (Canada Only, North America, Worldwide, etc.)


  • itemId - Item ID, used when viewing your order details.
  • transId - Transaction ID, used when viewing your order details.
  • itemid - Item ID, used when viewing your order’s tracking information.
  • transid - Transaction ID, used when viewing your order’s tracking information.

This is good enough for now until I order another product in the future. I am aware that hash is somehow ignoring uBlock Origin, so I will eventually get around to addressing it.

Worth a mention:
Open-source browser add-on ClearURLs: ClearURLs – Get this Extension for 🦊 Firefox (en-US)

1 Like

I took a look at their documentation and their rule catalog files.

To briefly compare and contrast between the methodologies:

  • I use an allowlist, whereas they use a blocklist with exceptions.
  • My rules are for services outside of Big Tech, whereas their rules are designed for users who directly continue to use Big Tech services (Amazon, Bing, Facebook, Google, Reddit, X, etc).
  • My eBay allowlist is well defined and fairly comprehensive for guest checkout, whereas their eBay blocklist only blocks 4 URL parameters.
    "ebay": {
      "urlPattern": "^https?:\\/\\/(?:[a-z0-9-]+\\.)*?ebay(?:\\.[a-z]{2,}){1,}",
      "rules": [
      "redirections": [
  • My wildcard filter rules have no exceptions, but their global filter rules allow tracking exceptions:
"exceptions": [

Another update:



  • _ssn - Seller Number, used when looking at other products by the same seller.
  • token - Token, used as a unique identifier when updating email preferences (such as unsubscribing).

Here is an untested value:

  • sessionid - Session ID, very likely used after completing the checkout process to show your order.

I watched someone else make an order on eBay and noticed the sessionid URL parameter after completing the checkout process, so I am assuming that it is required to display your order. Actual testing is needed to confirm this.

Small update:


This consolidates and whitelists all LH URL parameters, so now you can use the remaining search filters; I assume that this is the only purpose for them. I could optimize _, item and trans, but I need to carefully examine the URL to determine it is safe to do so.

I may order something with guest checkout sometime soon to confirm that these static filter rules continue to work as intended.

I figured out the issue with the hash URL parameter being ignored by uBlock Origin: since hash includes item as its value, it gets excluded. Here is a temporary solution for that by using two static filters:


Also, they include a wildcard, so all potential eBay TLDs (.com, .ca,,, etc.) are now affected by these rules.

I have fully confirmed that these uBlock Origin static filter rules work with eBay’s guest checkout. For reference, here are all of the static filter rules from this thread I currently use:


I have been working on removing URL parameters from TELUS:



  • category - Category, used as a value after eli-modal.js (“Eligibility Modal”) with the Offers API to display services.
  • client_id - Client ID, used for authentication with My TELUS.
  • locale - Locale, used with the Legals API to display legal terms and conditions.
  • next - Next URL, used for post-URL redirection for eli-modal.js with TELUS Business Internet plans.
  • redirect_uri - Redirect URI, used for post-URL redirection for logging in to My TELUS.
  • response_type - Response Type, value is code, used for authentication with My TELUS.
  • slugs - Used with the Legals API to display legal terms and conditions.

I have not authenticated with My TELUS just yet using these static filter rules, so I will continue updating it as time and space permits.