Turn URL query strings into JSON and back. Nothing is uploaded.
The Query String converter parses percent-encoded pairs with the browser's own URLSearchParams — where one non-ASCII byte costs three encoded characters (é = %C3%A9) — and never uploads the URL.
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.
No. This page never sends your input to a server — formatting, decoding and hashing all run in this tab, on this device.How that works.
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.
Browse allencoding toolsor thefull tool directory.