Every query string value is a string — until this converter guesses otherwise

A URL like ?page=2&active=true looks typed, but a URL carries no type information whatsoever. The 2 is a one-character string and true is a four-character string. This converter looks at each value and coerces the ones that look like something else: a value matching a number pattern (optional minus, digits, optional decimal part) becomes a JSON number, and the exact strings true and false become booleans. Everything else stays a string.

That convenience has a sharp edge, and it is worth knowing before you trust the output. version=1.10 becomes 1.1, because JSON numbers have no concept of a trailing zero. code=007 becomes 7, and the leading zeros that made it an identifier are gone. Anything that is written as digits but is not really a quantity — order references, zip codes, account numbers, version strings — is at risk. If you need those preserved exactly, fix them after conversion; the converter has no option to disable coercion.

Repeated keys collect into an array

A string like tag=red&tag=blue&tag=green is ambiguous by design — no standard says whether a repeat means "replace" or "add". This converter collects, producing {"tag": ["red", "blue", "green"]}. The first occurrence is stored as a plain value and the second promotes it to an array.

The consequence matters more than the rule: the output shape depends on the input data. One tag gives you a string; two give you an array. Code that reads result.tag and expects to iterate will work all through testing and then break on the single-tag case, which is precisely the case least likely to be in your fixtures. Normalise defensively — coerce to an array before you use it.

Plus signs become spaces, and percent-encoding is decoded

Query strings carry two different encodings for a space, and both are handled: the legacy + convention and standard percent-encoding. So q=hello+world yields "hello world", and name=Jos%C3%A9 yields "José". The plus is converted first, then the whole value is percent-decoded.

You can paste a complete URL — everything up to and including the first ? is discarded — or just the query portion, with or without a leading question mark.

Empty values and valueless keys are indistinguishable

Worth being precise about, because it is easy to assume otherwise. Both a= (a key with an empty value) and b (a key with no equals sign at all) produce an empty string: {"a": "", "b": ""}. The converter does not preserve the difference between them.

In HTML form terms those two cases can mean different things — a field submitted blank versus a field with no value component — so if that distinction matters to your application, it has to be encoded some other way before conversion, because it does not survive this step.

Nested objects via PHP-style bracket notation

Bracketed keys build nested structures rather than being treated as literal names. filters[year]=2026&filters[author]=ada produces {"filters": {"year": 2026, "author": "ada"}} — note that 2026 was coerced to a number on the way in, exactly as it would be at the top level. Numeric brackets such as items[0]=apple build arrays, empty brackets such as tags[]=a&tags[]=b append, and the forms nest to arbitrary depth.

This mirrors how PHP and most HTML form libraries serialise structured data, so a form submission usually round-trips into the shape you expect. Bear in mind that many other query-string parsers do not implement this and will hand you a literal key named filters[year] instead — so if you are comparing output against another tool, that is the likely reason they differ.

See also the cURL to Fetch and SQL to JSON converters, or turn the result into code with JSON to TypeScript or JSON to Go Struct.