Parsing query params means taking the query component of a URL — the text after the question mark such as tag=js&tag=api — and turning it into structured data the receiving code can use, while honoring the WHATWG application/x-www-form-urlencoded rules for percent escapes, plus-as-space decoding, and repeated parameter names. Each pair is split on the first equals sign, percent escapes are decoded to characters, plus signs become literal spaces, and key names that appear more than once are kept as an ordered list of values rather than being silently overwritten. Empty values, missing equals signs, and reserved characters that appear inside a value rather than acting as separators are all part of the contract and must survive the round trip without surprise mutations. The Query String Parser implements these rules directly in the browser using the URLSearchParams model, so no query text, JSON, or identifier leaves your machine. Knowing the exact rules matters because different servers treat duplicate keys differently — some keep the first value, some keep the last, and some always produce an array — and the wrong assumption produces a payload that looks valid but means something different to the receiver.
What Parsing Query Params Actually Does
A query component is a flat sequence of key=value pairs separated by ampersands. Parsing it well requires three concrete behaviors: splitting on the first equals sign only, decoding percent escapes using UTF-8 bytes, and treating literal plus signs as spaces. The WHATWG URL Standard defines these rules in section 6 for URLSearchParams, and MDN documents the same implementation for the browser's built-in constructor. Following them keeps the parsed value semantically equivalent to the source after re-encoding, though percent-escape spelling and plus-versus-%20 choices are normalized on serialization.
The leading question mark is not part of the data, so a well-behaved parser tolerates its presence or absence. The output should likewise be a plain query component without the question mark, because callers may need to insert it into a URL, an HTTP request body, a log fixture, or a unit test in isolation. Removing that ambiguity is what makes the result predictable across contexts.
Why a Dedicated Parser Beats Hand-Rolled Code
A naive split("&") followed by split("=") works for the trivial case but breaks on values that contain reserved characters, on empty values, on missing equals signs, and on duplicate keys. Common failure modes include:
- Treating a plus sign as a literal character instead of a space
- Splitting on every equals sign and corrupting values that contain =
- Dropping later occurrences of duplicate keys when the data shape actually needs an array
- Confusing the path of a full URL for part of a parameter name when the caller pastes a complete URL by mistake
- Sorting the keys alphabetically, which silently changes the signature of a signed URL
A dedicated parser handles these edge cases through one implementation, applies the WHATWG decoding rules consistently, and returns a shape that mirrors what the wire format actually carries — text, not guessed types.
How to Parse Query Params With the Query String Parser
- Open the Query String Parser in your browser and choose the query-to-JSON direction for parsing or the JSON-to-query direction for building.
- Paste the source text into the input field. For parsing, paste the query component with or without a leading question mark. For building, paste a flat JSON object whose values are strings, finite numbers, booleans, null, or arrays of those scalars.
- Run the conversion. The tool decodes percent escapes, treats plus signs as spaces, preserves empty values, and keeps repeated parameter names as ordered JSON arrays.
- Inspect the result for repeated keys (which appear as arrays) and empty values (which appear as empty strings) so you know exactly what the receiver will see.
- Copy the output and validate it against the API or endpoint that will consume it before you ship the value downstream.
Conversion Rules: Duplicates, Empty Values, and Encoding
The parser follows a small, explicit set of rules so the output is predictable. The table below shows how each kind of input is handled.
| Input | Behavior | Output |
|---|---|---|
| tag=a&tag=b | Repeated names kept in encounter order | "tag": ["a", "b"] |
| q=hello+world | Plus sign decoded as space | "q": "hello world" |
| name=John%20Doe | UTF-8 percent escapes decoded | "name": "John Doe" |
| flag&ok=1 | Missing equals treated as empty value | "flag": "", "ok": "1" |
| note=a%26b | Encoded ampersand kept inside a value | "note": "a&b" |
| ?page=2 | Leading question mark stripped | "page": "2" |
The same rules apply in reverse. A space serializes back as a plus, a literal plus is percent-encoded so it is not mistaken for a space, and reserved characters such as ampersand and equals are percent-encoded when they belong to a value rather than acting as separators. There is no type inference: the text 2 remains the JSON string "2" when parsed from a query, because the wire format carries text, not a numeric type declaration.
Building Query Strings From JSON
In the JSON-to-query direction the tool accepts a deliberately limited JSON shape: strings, finite JSON numbers, booleans, null, and arrays of those scalar values. Nested objects and nested arrays are rejected because there is no single standard for representing nested data inside a query string — bracket notation, dotted names, indexed names, and embedded JSON are competing conventions, and guessing would create output that looks valid but means something different to another parser.
Empty arrays are omitted because they contain no value to append. null becomes an empty value, while JSON numbers and booleans become their textual forms. This produces a payload that is faithful to the source and avoids the trap of the integer 2 silently becoming the string "2" or vice versa on the receiving end.
When Not to Re-Encode: Signed URLs and Cache Keys
Sorting, rebuilding, or normalizing query parameters can break signed URLs and cache keys. Order, duplicate occurrence, percent-escape spelling, and plus-versus-%20 choices may all be covered by a signature, so changing any of them invalidates the signature downstream of the tool. Preserve the original serialized bytes unless the signing protocol explicitly defines a canonicalization algorithm.
This applies whenever the URL contains a token, hash, signature, or sig parameter computed over the exact bytes of the query component. If the protocol is unknown, the safe path is to copy the query text without modification and to use a protocol-specific encoder — or, where none exists, the URL Parser to inspect the existing components before changing anything.
Limits, Privacy, and What to Validate
The tool bounds input at 200,000 characters in the current tab and runs entirely in the browser, so no query text, JSON, token, identifier, or URL is uploaded to a server. Even so, query strings frequently carry session identifiers, email addresses, search terms, and tracking values, and browsers, history, analytics, proxies, referrers, and server logs can retain them independently of the tool. Redact sensitive data before sharing output.
The parser does not validate a complete URL, hostname, path, fragment, signature, or authorization policy. If a full URL is pasted, its path can be mistaken for part of a parameter name, so use a URL component parser first when you need URL-level validation. Finally, confirm the contract of the receiving application before sending generated data, because frameworks differ in how they treat duplicate keys, empty values, and the encoding of reserved characters.