Query String to JSON Converter
Parse a URL query string into a JSON object.
Parsing query strings
This tool reads the parameters after the ? in a URL — or a bare query string — and turns them into a tidy JSON object, decoding any percent-encoded characters along the way. Keys keep the order they have in the query, and repeated keys (like tags=new&tags=sale) collapse into an array. A key with no = is null, so it stays distinct from an empty value. Paste a full link and only its query is read. The fragment after the # never reaches a server, so it is left out, with a note under the output when it held parameters. A link with no query but parameters in its fragment, such as a single-page app route, is read from the fragment instead. Parsing happens entirely in your browser.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Turning a long URL's parameters into a readable object while debugging.
- Converting a captured request's query into a JSON body for a test.
- Checking how repeated parameters are being interpreted.
- Extracting parameters from a logged URL for analysis.
- Producing a structured view of a tracking URL's parameters.
Frequently Asked Questions
- Can I paste a whole URL?
- Yes. In an address, or a path like
/search?q=1, everything up to the first?is dropped, and the#fragmentis cut off: it never reaches the server. In a barea=1&b=2, a?stays in its value, sonext=/cart?step=2is one parameter. An address with parameters only in its fragment is read from it, with a note. - What happens to repeated keys?
- They become an array:
tag=a&tag=bgives{"tag": ["a", "b"]}. There is no standard for repeated parameters — PHP wantstag[]=a, Rails accepts both, and some frameworks keep only the last — so the array is the lossless reading. - Do the keys keep their order?
- Yes. Each key sits in the JSON where it first appears in the query, even a key such as
2, which a JavaScript object would move to the front. Any name is read as written, so__proto__,constructorandtoStringare ordinary keys, not dropped or misread. - Is the percent-encoding decoded?
- Yes, using the URL standard's own parser, so
%20and+both become a space and%26becomes a literal ampersand. That plus-sign rule is specific to query strings: in a path segment,+means a plus. Bytes that are not UTF-8, such as Latin-1's%E9for é, become U+FFFD, with a note naming the key. - Are values typed?
- No — everything is a string, because a query string carries no type information.
?count=5&flag=truegives"5"and"true"as strings, and converting them is your application's job. Anything else would be guessing. - What about nested parameters?
user[name]=xproduces the literal keyuser[name]rather than a nested object, because the bracket convention is a framework habit, not part of any specification. Rebuild the nesting in your own code if your backend uses it.- Should a key with no value become an empty string or null?
?flagand?flag=are different in principle, yet the browser's URLSearchParams, PHP and Express read both as an empty string. This converter gives null for the first and an empty string for the second, which keeps the distinction that matters for feature flags, and a note names each key with no=.
Common errors and gotchas
- Assuming repeated keys become an array, when many parsers keep only the first or the last.
- Losing the distinction between a missing parameter and one present with an empty value.
- Failing to decode percent-encoding, so values keep their escape sequences.
- Treating
+as a literal plus in a form-encoded query, where it means a space. - Expecting nested structure from bracket notation, which is a convention rather than a standard.
- Pasting an address copied from HTML source, where each & is written & and every key after the first gains an amp; prefix.
- Writing a # inside a value unencoded, which ends the query there, so the server never sees the rest; it must be %23.