Paste a query string or a full URL to turn percent-encoded pairs into JSON, or JSON into a query string. Parsing uses the browser's URLSearchParams; repeated keys become arrays and values stay strings. Nested JSON is rejected with the offending key named. Useful for logs, OAuth callbacks and copying params into fixtures. Nothing is uploaded.
Runs in this tab · nothing is uploaded · Verify in 10 seconds →
A query string packs key=value pairs after the ? of a URL; this converter turns those pairs into a readable JSON object and turns a flat JSON object back into a properly encoded query string. Use it to inspect tracking parameters, debug API calls, or build a query string without hand-encoding every value.
Paste a full URL or a bare a=1&b=2 string, everything before the first ? (and any #fragment) is stripped, then the pairs are parsed with your browser's own URLSearchParams, which implements the WHATWG URL standard. Going the other way, each JSON key is appended to a fresh URLSearchParams and serialized with correct percent-encoding. Both directions run entirely in this tab.
~/faq
They become a JSON array: {"tags": ["a", "b"]}. Query strings have no official convention for lists, so this tool picks the repeated-key style; converting the array back emits tags=a&tags=b again, making the round trip lossless.
A query string is a flat list of string pairs. There is no standard way to encode {"user": {"name": "Ada"}}. The tool shows an error naming the offending key instead of guessing at a bracket convention like user[name] that only some frameworks understand. Only string, number and boolean values (and arrays of those) convert.
URLSearchParams follows the application/x-www-form-urlencoded rules from the WHATWG URL standard, where + means a space. A literal plus sign must be encoded as %2B. When serializing, spaces come out as + again, which every server-side parser understands.
Yes. A query string carries no type information (page=2 could mean the number 2 or the string "2"), so every value is kept as a string rather than guessed. Going from JSON to a query string, numbers and booleans are accepted and serialized as their text form.
Mostly. Keys keep their first-appearance order, but values of a repeated key are grouped into one array, so a=1&b=2&a=3 comes back as a=1&a=3&b=2. Servers treat parameter order as insignificant, so this does not change meaning.
No. Parsing and serializing both use the URLSearchParams API built into your browser; LocalFirstTools has no server endpoint that receives what you paste.
Chosen for the same job, not just the same category.