Six Query Shapes, 56 Pages: What a Repeated, Blank or Encoded Tracking Parameter Does to Our Own Site

I work on OnePassApps, the team behind app.onepassapps.com. This post is about a gap in our own earlier measurement: what the site does with tracking parameters that are not the exact shape we used then. Everything below was measured on 10 November 2026, from outside the browser, signed out, plain HTTPS, no cookies and no JavaScript.

On 8 November we published the tracking-link contract for all 56 URLs in our sitemap: a bare GET and a tracked GET came back the same length, and once Cloudflare's per-request email-obfuscation token was normalised the two documents matched byte for byte. That post also said plainly what it had not tested - other parameter names, repeated parameters, or a URL-encoded value. This post closes that list, and adds one thing the earlier post did not look for: whether a parameter value turns up anywhere else in the document.

The six shapes

I took four pages from our own sitemap - the home page, the guides, the Image Studio and MovieMatcherAI - and asked each one for the same six query strings:

• ? on its own
• ?foo=bar, a parameter name the site has never heard of
• ?utm_source=a&utm_source=b, the same name twice
• ?utm_source=, a name with no value
• ?utm_source=%20a%20b, a URL-encoded value
• the full utm_source / utm_medium / utm_campaign / utm_content set plus an extra gclid

That is 24 responses, against four bare fetches to compare them with. Every one of the 24 answered 200. Every one came back at the same length as its bare counterpart - 24,977 bytes on the home page, 61,739 on the guides, 17,208 on the Image Studio and 19,277 on MovieMatcherAI. And every one of the 24 matched its bare fetch byte for byte, once the two Cloudflare email-obfuscation values were normalised.

So a repeated parameter is not an error here, a blank value is not an error, an encoded value is not an error, and a parameter name we invented is not an error either. The app host reads none of it.

The 56-page sweep again, with one extra question

I repeated the bare-versus-tracked pair across all 56 sitemap URLs with the full four-parameter set, and this time looked for the parameter values anywhere in the document, not only in the canonical link and the social card.

• All 56 answered 200 on both fetches, and all 56 pairs came back at the same length.
• All 56 documents matched byte for byte after the email-obfuscation normalisation. Raw and unnormalised, 0 of the 56 pairs were identical - every difference sat in the data-cfemail attribute and the /cdn-cgi/l/email-protection# hex, which is the per-request key we wrote about on its own.
• On 0 of the 56 pages did any of the four parameter values appear anywhere in the HTML - not in a tag, not in a script, not in a comment. The canonical link and the og:url both point at the bare address on 56 of 56.

The API host, for contrast

Our API host answers the same question the same way, and it is where a request id shows up. Both /api/products and /api/runtime answered 200 with and without the four parameters, at identical lengths - 15,650 and 471 bytes - and neither echoed a parameter value. The only bytes that differed between the two answers were the per-request id, in the body and in the x-request-id header: req_S1Ov1EuYbNp_XFa_ on one fetch, req_e_4OjPscirn9ohdf on the next.

One redirect check

A tracked URL that points at a route which exists does not redirect. /guides?utm_source=x and /studios/image?utm_source=x both answered 200 directly, with no redirect in the way.

What this means when you share a link

• The shape of the query string does not matter. Repeat a name, blank it, encode it, invent a new one - the page is the page.
• Nothing you put in the query string ends up in the document, so a campaign parameter cannot turn into a second version of the page, and it cannot leak into a crawler.
• If you tag a link to a route that exists, you get that route, not a bounce.

Limits

• One build, one day, 10 November 2026, plain HTTPS from one machine, signed out, no cookies, no JavaScript.
• The six shapes were swept over four pages, not all 56. The 56-page sweep used the full four-parameter set.
• Byte-identity means after normalising the two Cloudflare email-obfuscation values. Raw bytes differ on all 56 pairs, because that key is fresh on every request.
• This is about the server's answer. It says nothing about what a visitor's analytics tool does with the parameters afterwards.

Try it yourself

The home page is where all the apps are listed, and every one of them runs in your browser tab: the OnePassApps home page

Every app and studio has a plain-language guide with its limits and its tool list: the OnePassApps guides