A short link can hide a long query string without removing any of it. We tested da.gd, zip1.io, Yandex Clicker (clck.ru), Shrtr (shrtr.top) and 4Lin (4lin.uk) on 12 Oct 2026 to see what happened to parameters already in a URL—and to parameters added after shortening.
Quick answer
In our five-service test, all 89 accepted inputs redirected to the exact URL supplied, including its existing parameters. One of 90 inputs was rejected. Parameters added to the short link behaved differently: four services ignored them, and da.gd forwarded them but did not merge an already populated query correctly in our example. Put required parameters in the destination before shortening, then inspect the resulting redirect.
Contents
- Parameters before shortening
- Parameters after shortening
- The extra question mark in our da.gd result
- Redirect chains and the rejected input
- Shortening a URL versus cleaning it
- How we tested and what the results cover
Parameters before shortening
UTM parameters identify the source, medium and campaign associated with a referral link in Google Analytics. Google’s campaign-URL documentation describes adding those values to the destination URL. Their purpose is attribution, so preserving them can be exactly what a campaign creator wants.
Our fixed set contained 18 synthetic URLs. It covered UTM tags, synthetic click-ID values such as gclid, functional-looking fields such as q and page, mixed query strings, duplicate keys, encoding, Unicode, empty values and fragments. We supplied the same set to each service through its no-account API route.
| Service | Attempted | Exact URL preserved | Rejected |
|---|---|---|---|
| da.gd | 18 | 18 | 0 |
| zip1.io | 18 | 17 | 1 |
| Yandex Clicker (clck.ru) | 18 | 18 | 0 |
| Shrtr (shrtr.top) | 18 | 18 | 0 |
| 4Lin (4lin.uk) | 18 | 18 | 0 |
“Exact URL” means the declared destination matched the supplied text, including query order, duplicate keys and encoding. The services did not just retain the UTM names while rewriting everything around them. This is a result for these accepted inputs, not a guarantee for every URL or provider.
Fields such as q and page also survived. We call them functional-looking because they commonly represent search and pagination state; our example.com fixtures did not run a search or pagination application. Keeping their text is narrower evidence than proving that an application behaved correctly.
Parameters after shortening
Appending ?utm_source=newsletter to a short link asks the shortener to decide what to do with a new query string. That is a different operation from shortening a destination that already contains utm_source.
We tested a new UTM value and a q value on short links whose stored destinations had no query. We also added a conflicting utm_source value to a short link whose destination already contained several parameters.
| Service | New UTM; no stored query | New q; no stored query | UTM added to stored query |
|---|---|---|---|
| da.gd | Forwarded | Forwarded | Literal text added inside the gclid value |
| zip1.io | Ignored | Ignored | Stored destination unchanged |
| Yandex Clicker (clck.ru) | Ignored | Ignored | Stored destination unchanged |
| Shrtr (shrtr.top) | Ignored | Ignored | Stored destination unchanged |
| 4Lin (4lin.uk) | Ignored | Ignored | Stored destination unchanged |
Here, “ignored” means the declared destination was unchanged. It does not mean the service first forwarded a parameter and the destination then removed it. The q probe followed the same pattern as the new UTM probe.
Forwarding and merge rules vary by service and configuration. Short.io’s parameter-merging documentation, for example, describes merging by default, allowing an incoming value to replace a stored value, and a setting to disable merging. We researched that documentation; Short.io was not one of our five completed live tests.
For a campaign, build the intended destination—including its campaign and functional parameters—before shortening it. If you need to change attribution by adding parameters to an existing short link, check that service’s forwarding rules and inspect the actual redirect. A parameter visible on the short link may never appear at the destination.
The extra question mark in our da.gd result
Our stored destination for the conflicting-UTM probe was:
https://example.com/?q=blue&page=2&utm_source=synthetic&utm_campaign=em-study&gclid=synthetic-gWe added ?utm_source=override to the returned short link. da.gd’s redirect declared:
https://example.com/?q=blue&page=2&utm_source=synthetic&utm_campaign=em-study&gclid=synthetic-g?utm_source=overrideUnder ordinary ampersand-separated query parsing, utm_source still has the value synthetic. The final gclid value becomes synthetic-g?utm_source=override. The added text is inside that value, rather than becoming a replacement utm_source field.
The second question mark does not automatically make the URL invalid: the URI specification allows a question mark within the query component. The problem in this fixture is the result’s meaning. It did not achieve the intended parameter merge.
A repeated read produced the same destination. This gives us a concrete example to check for, without establishing that every da.gd link or future version will behave identically.
Redirect chains and the rejected input
da.gd, zip1.io, Shrtr and 4Lin exposed one HTTP 302 redirect to the supplied destination. Yandex Clicker exposed two: clck.ru redirected through sba.yandex.ru/redirect before declaring the supplied destination.
Yandex’s intermediate URL contained provider-generated fields and an encoded destination. Those fields belonged to the intermediate hop; they were not new query parameters on the final destination. The chain alone does not establish what analytics the provider collected.
zip1.io rejected our combined empty-value and bare-key input with HTTP 400:
https://example.com/?empty=&bare&zero=0Two exploratory followups helped narrow the difference: ?empty=&zero=0 was accepted and preserved, while ?bare&zero=0 was rejected. These are observations about the tested examples. We did not replace the rejected case in the main results or turn the followups into a universal validation rule.
Shortening a URL versus cleaning it
The existing tracking parameters in our accepted inputs remained present at the declared destinations. A shorter visible address therefore gave no evidence that those parameters had been removed.
If you are sharing a destination without its recognized tracking fields, start with the original long URL when you have it. Our URL Cleaner can review known tracking parameters locally while keeping unknown and potentially functional fields by default. It does not follow short links or inspect destinations hidden behind them.
For repeated cleaning of copied or eligible clicked links, URL Cleaner by Elegant Matter is available as a Chrome extension. It is a separate workflow from expanding a short link: removing visible parameters from an alias does not reveal or clean the stored destination.
For your own campaign, retaining UTM parameters may be intentional. For ordinary sharing, remove only parameters you understand or that a conservative rule identifies; search terms, product options and authentication state can matter. Recognized signed links need particular care because changing their query can break access.
A destination with fewer tracking fields is also a limited result. Our test did not measure provider logs, cookies, fingerprinting, attribution reports or the safety of a destination. Parameter preservation and privacy are separate questions.
How we tested and what the results cover
Our study used Python 3.12.14 and standard-library HTTP requests. The original batch, EM-SHORTURL-20261012-01, covered three services; expansion batch EM-SHORTURL-20261012-02 added Shrtr and 4Lin using the same 18 URLs. We used synthetic example.com URLs, synthetic click-ID values and no account credentials or personal browser profile. Outer request encoding kept each supplied URL intact during link creation.
Automatic redirects were disabled. We recorded response status and Location at each allowed hop, resolved relative references and compared the declared destination with the original URI. Location is the HTTP response field used to identify a redirect target.
Two initial pilots fetched Example Domain. After that, the resolver stopped when the service declared the example.com destination. The measured outcome is therefore the destination URI exposed by the redirect, not receipt by a destination server or successful behavior inside an application.
We resolved every accepted main-corpus link again. Of the first 89 repeat attempts, 88 exposed the same destination and one zip1.io read timed out. An additional recorded read of that link exposed the original exact URI. The timeout remains a failure in the record; these reads are not a long-term reliability benchmark.
The three query-modification probes shown above were also repeated for each provider. A fourth modification concerned fragments. Fragments were removed from outgoing HTTP requests, and inheritance was modeled by our resolver; that part was not an observed browser test. Stored fragments were included in the exact-URI checks.
Only five services completed the common corpus. Supported API routes for Bitly, TinyURL, Short.io and T.LY required credentials we did not have. Other candidates returned access errors or timeouts in our environment. Spoo.me and ShrinkRL created links whose public redirects returned HTTP 403; their preservation behavior remained unobserved. Access failures do not establish parameter loss.
The original protocol existed before the first creation and was amended after pilots and for the third-provider extension. A separate expansion protocol reused the same cases and recorded later candidate additions. 4Lin returned an existing alias for the baseline input, so not every observed link was newly created. We retained rejected inputs, exploratory followups and repeat failures. We did not test paid plans, custom domains, browser interfaces, nested shorteners, speed, advertising attribution or long-term link survival.
Sources and verification
- Google Analytics: campaign URL parameters
- Short.io: query-string merging and its disable setting
- RFC 3986, section 3.4: query-component syntax
- RFC 9110, section 10.2.2: Location
- da.gd: shortening and destination-inspection help
- zip1.io: API documentation
- Yandex Clicker: official service
- Shrtr: API documentation
- 4Lin: API documentation
Original observations: Elegant Matter, 12 Oct 2026; EM-SHORTURL-20261012-01 and EM-SHORTURL-20261012-02.