Query String Parser
Every parameter, decoded, with repeated keys shown as a list rather than silently overwritten.
What is inside a query string
Everything after the ? and before the # is the query component. It is a sequence of key=value pairs joined by & — conventionally, not by any standard. Each pair is application/x-www-form-urlencoded, which means spaces may appear as +, and any byte outside the unreserved set appears as a percent-triplet derived from its UTF-8 encoding.
Four things that quietly corrupt parameters
- Repeated keys.
?tag=a&tag=bhas no standard meaning for a single value. Some frameworks keep the first, some keep the last, some produce an array. If you see an array in the table, that is the honest answer — the string really does contain two values. +versus%20. In a query,+means space. A Base64 parameter containing+is therefore silently mangled unless it was percent-encoded as%2Bon the way out.- Keys with no
=.?debugis a flag with an empty value, not an error. It is extremely common and should be reported as present with an empty string. - Double encoding.
%2520decodes to the literal text%20, not to a space. It means a value was encoded twice, and the receiver will see a string containing a percent sign.
Why the parameters are not in the order you sent them
Nothing requires parameter order to be preserved, and most server frameworks store parameters in a map. A canonicalised URL — the form used for caching keys and signature computation — usually sorts parameters alphabetically and normalises encoding, precisely because the received order is not dependable. If your cache is producing more misses than the hit rate suggests, unsorted query parameters are a common cause.
Reading a tracking-heavy URL
Marketing links routinely carry a dozen parameters. utm_source, utm_medium and utm_campaign describe the campaign; gclid, fbclid and their relatives are click identifiers that let the ad platform match the visit to the click. When you paste one here, the table shows which parameters are yours and which were appended by whoever shared the link — which is the fastest way to tell whether a link was copied from an ad or from the address bar.
When you are debugging a server, parse the query string on the server and log the decoded values. Logging the raw form means a %2B mystery reaches production before anyone notices it is a plus sign.
How to use it
- Paste a full URL or just the query portion.
- Read the table of decoded key and value pairs.
- Check for repeated keys and for empty-valued flags.
- Note any value containing a literal percent sign — that is a sign of double encoding.
Worth knowing
- The query component runs from
?to the first#. +means space in query strings, but only there — not in a path.- Repeated keys have no standard resolution; behaviour is framework-specific.
- Percent-triplets come from UTF-8 bytes, so one CJK character becomes three of them.
Limitations
- No validation that the URL is well formed or reachable.
- Parameter ordering as received is not meaningful and is not preserved upstream.
- Semicolons as separators were encouraged by early specs and are not handled by most modern parsers.
- This shows what the string contains, not what the server did with it.
Frequently asked questions
Why did my `+` turn into a space?
+ is defined as space. Percent-encode a literal plus as %2B on the way out.How are duplicate parameters handled?
What are utm parameters?
utm_source, utm_medium, utm_campaign, sometimes utm_content and utm_term — appended by analytics tools so the visit can be attributed to a specific link.What does `%2520` mean?
%20 was encoded again so its percent sign became %25. The receiver sees the literal characters %20 rather than a space.