How this tool fits your workflow
What this converts
Query strings carry parameters in a URL after the question mark. They are easy to read when short and quickly become unreadable when long — a tracking URL with eight UTM parameters and a filter set is not something you can check by eye.
Converting to JSON gives you one parameter per line, properly decoded, so you can see exactly what a URL is carrying. The reverse direction builds a correctly encoded query string from structured data.
Worked example: a tracking URL
Take a campaign URL with UTM parameters, a repeated filter, and an encoded value:
- Paste the query string, or the entire URL, into the left pane.
- Read the decoded parameters as JSON on the right, one per line.
- Switch direction to build a query string from a JSON object — array values automatically repeat the key.
| Parameter | JSON key | JSON value |
|---|---|---|
| utm_source=newsletter | utm_source | "newsletter" |
| utm_medium=email | utm_medium | "email" |
| tag=react&tag=seo | tag | ["react", "seo"] |
| page=2 | page | "2" ← string, not number |
| q=hello%20world | q | "hello world" ← decoded |
| flag= | flag | "" ← empty, not null |
Everything is a string
Like environment variables, query parameters have exactly one type. ?page=2 gives you the string "2", and ?active=false gives you the string "false" — which is truthy.
This is a routine source of bugs in request handlers. Coerce explicitly at the boundary: parse integers with Number() and check for NaN, and compare booleans against the literal string "true" rather than relying on truthiness.
Common mistakes
- Confusing an empty parameter with a missing one. ?flag= gives an empty string; omitting flag entirely gives no key at all. Server code often treats these differently.
- Forgetting that + means space in query strings. Historically a plus sign decodes to a space, which is why a literal plus must be encoded as %2B. This bites when passing phone numbers or base64 values.
- Putting secrets in query strings. URLs are logged by servers, proxies, browser history and analytics. Tokens and passwords belong in headers or a request body, never in a URL.
- Assuming a length limit is generous. Browsers and servers cap URL length — around 2,000 characters is the practical safe limit. Long filter sets belong in a POST body.
- Hand-building query strings with string concatenation. It is how encoding bugs get introduced. Build from structured data and let the encoder handle escaping.
When not to use this
Related workflow
For encoding or decoding an individual value rather than a whole query string, the URL encoder and decoder handles single strings.
If the parameters arrived from a form submission and you need them as a table, flatten the JSON with the JSON flattener and then use the CSV and JSON converter.
The JSON formatter validates and reformats the output if you intend to paste it into a config file or test fixture.
Frequently asked questions
- Can I paste a whole URL?
- Yes. Everything before the question mark is ignored, so you can paste a full URL straight from the address bar without trimming it first.
- What happens to repeated parameters?
- They become an array. ?tag=react&tag=seo produces { "tag": ["react", "seo"] }, which is how most server frameworks interpret repeated keys.
- Does it handle URL encoding?
- Yes, in both directions. Percent-encoded sequences are decoded when parsing, and special characters are encoded when building a query string.
- Are all values strings?
- Yes. A query string has no types, so ?page=2 gives the string "2", not the number 2. Convert explicitly in your code if you need a number.
- What about nested objects?
- Query strings are flat. A nested object is serialised to a JSON string as the value. Different frameworks encode nesting differently, so there is no single correct behaviour here.