Parsing a URL query string means converting the text after the question mark in a URL — the part that looks like a sequence of key and value pairs joined by ampersands — into a structured form a program can read, log, validate, or modify. The result is usually a plain object or map where each parameter name maps to its decoded value, with repeated names collected into arrays and reserved characters restored to their literal form. Decoding rules follow the WHATWG URL Standard: percent escapes resolve to bytes, plus signs become spaces, and UTF-8 byte sequences convert back into the original Unicode characters. A practical parser also has to decide what to do with empty values, missing equals signs, and named duplicates, because those choices determine whether downstream code receives the data the server actually expects. The Query String Parser tool carries out this conversion in the browser using the same model as the browser-native URLSearchParams API, and it can reverse the process so you can build a query string back from a flat JSON object.
What a query string actually contains
Before running a parser, it helps to know what a query string is and what it is not. A query string is the portion of a URL that follows a question mark and carries parameters to a server. Each parameter uses an equals sign to separate a name from a value, and parameters are joined by ampersands. A typical example might be a search URL of the form /search?q=hello+world&page=2&tag=news&tag=tech, where two tags arrive as a repeated key rather than a single comma-separated string.
Three details make query strings tricky to handle by hand. First, percent escapes encode any byte that does not fit in plain ASCII: a space can appear as %20, and a non-ASCII character such as é arrives as the byte sequence %C3%A9. Second, plus signs represent spaces in this format, so a literal search for "hello world" really does arrive as hello+world and must be decoded back to a space character. Third, the same parameter name can appear more than once, and the receiver has to decide whether to keep both, keep one, merge them into a list, or pick a specific occurrence by position.
Because of these conventions, treating a query string as a normal string and splitting on ampersand and equals is enough to read trivial cases but breaks the moment a value contains a literal ampersand, an equals sign, or a non-ASCII letter. A purpose-built parser resolves those bytes according to a documented rule set rather than guessing, which is why API debugging and request logging lean on the same form-decoding model browsers use internally.
How to parse a query string into JSON
- Open the Query String Parser tool and leave the default direction, query to JSON, selected.
- Paste the query component into the input field. You can include or omit the leading question mark; both forms are accepted.
- Run the conversion. The tool decodes percent escapes, converts plus signs back into spaces, and turns the parameter list into a flat JSON object.
- Inspect the output for repeated names, which appear as arrays in encounter order, and for empty values that intentionally lack content on the right side of the equals sign.
- Copy the JSON and validate it against the receiving API by sending a request with the parsed parameters to confirm the server interprets them as you expect.
This same direction is useful when logging a request, building a fixture from a captured URL, or comparing two requests parameter by parameter. Because the conversion happens locally, the query text does not leave the browser during this step, and the output is a query component without a leading question mark so you can paste it into a URL prefix, a request body, or a saved log without an extra trim step.
Building a query string back from JSON
The reverse direction is just as useful as parsing. Given a flat JSON object, you can rebuild an encoded query component for a URL, a request body, or a saved test fixture. The tool accepts strings, finite JSON numbers, booleans, null, and arrays of those scalar values, then applies the same encoding rules browsers use for forms. A single occurrence of a key stays a string, while an array keeps every value in order so the receiving server sees the same duplicates the source had.
Null becomes an empty value, and JSON numbers and booleans become their textual form. Empty arrays are dropped because they would contribute no parameter to encode, and nested objects are rejected outright. That last constraint reflects a real limitation in the wire format: query strings have no single agreed-upon way to serialize nested data, so brackets, dotted names, indexed names, and embedded JSON are all competing conventions. Choosing one silently would produce output that means something different to another parser, so the tool refuses to guess.
The output omits the leading question mark for the same reason as the parse direction. Callers may need to drop the parameters into a URL prefix, place them into a request body, log them independently, or compare them against a baseline, and a stray question mark in any of those contexts would break the next step.
How duplicates, empty values, and types are handled
| Scenario | Source shape | Result in the opposite format |
|---|---|---|
| Single occurrence | ?tag=news | {"tag":"news"} |
| Repeated key | ?tag=news&tag;=tech | {"tag":["news","tech"]} |
| Plus sign as space | ?q=hello+world | {"q":"hello world"} |
| Percent escape | ?name=%C3%A9 | {"name":"é"} |
| Empty value | ?debug= | {"debug":""} |
| Missing equals sign | ?flag | {"flag":""} |
| Reserved character in value | ?note=a%26b | {"note":"a&b;"} |
Type inference is intentionally not performed. The byte sequence 2 arrives over the wire as text, so it becomes the JSON string "2" rather than the number 2. If your consumer expects a typed value, cast it after parsing rather than relying on the parser to guess. For the full set of decoding rules this tool follows, see the MDN URLSearchParams reference and the WHATWG URL Standard.
Limits, signed URLs, and what not to put in a query string
The tool caps input at 200,000 characters per conversion, which is well beyond anything a normal request needs but small enough to keep the page responsive. Every operation runs in the current tab, so query text, JSON, tokens, and URLs are not uploaded to a server. That local-only guarantee is useful, but it does not erase the larger reality that query strings frequently end up in browser history, server logs, proxies, referrer headers, and analytics tools. Session identifiers, email addresses, search terms, and tracking tags routinely leak through that path regardless of which parser you use. Redact sensitive data before sharing a parsed result, or avoid putting secrets in URLs entirely.
If you need to inspect a full URL rather than just its query, run that URL through a dedicated URL parser first. Pasting a complete URL into a query-only parser can confuse the path with a parameter name, because parsing does not validate a complete URL, hostname, path, fragment, signature, or authorization policy. Reordering, deduplicating, or re-encoding query parameters can also invalidate signed URLs whose signature covers parameter order, duplicate occurrence, percent-escape spelling, and the plus-versus-%20 choice. When a protocol defines an official canonicalization — for example, an OAuth signature algorithm or a payment request format — use that protocol's encoder instead of a general-purpose converter. The Query String Parser is meant for ordinary request inspection, log fixtures, and test data, not for rebuilding signed payloads.
Because the tool follows the WHATWG application/x-www-form-urlencoded rules, the behavior you see in a browser matches what the converter produces, and the test fixtures that lock single pairs, duplicate names, plus-to-space decoding, UTF-8 text, missing equals signs, empty values, reserved characters, and the optional leading question mark cover the cases most teams encounter. When the receiving server uses a different convention — keeping the first value, keeping the last, always creating arrays, or splitting on commas — confirm its contract before trusting parsed data as canonical.