Use Query String Parser by choosing query-to-JSON or JSON-to-query, pasting a query component or flat JSON object, running the conversion, inspecting repeated or empty values, and validating the copied result against the receiving API. The Query String Parser handles both directions in the browser: it turns an application/x-www-form-urlencoded query component into readable JSON, or builds a query component from a deliberately limited, flat JSON object. For parsing, it accepts text with or without a leading question mark, decodes percent escapes, treats plus signs as spaces, keeps empty values, and turns repeated names into arrays in encounter order. For building, it accepts strings, finite JSON numbers, booleans, null, and arrays of those scalar values; it rejects nested objects and nested arrays rather than guessing at a nesting convention. The generated result omits the leading question mark so you can place it into a URL, request body, log fixture, or test. It is a conversion and inspection aid, not a complete URL validator or a guarantee that every server handles duplicates, nulls, or parameter order the same way.
Choose the right conversion direction
Start by deciding which side of the conversion you need. Query-to-JSON is for inspecting parameters already carried in a query component. JSON-to-query is for creating encoded parameters from structured input. Do not use JSON-to-query for an arbitrary JSON document, because the accepted object is intentionally flat and its values must follow a defined scalar policy.
| Mode | Input | Output | Main boundary |
|---|---|---|---|
| Query-to-JSON | A query component, with or without a leading question mark | Readable, decoded JSON | Parsed text does not receive inferred numeric types |
| JSON-to-query | A flat JSON object | An encoded query component without a leading question mark | Nested data is rejected; empty arrays are omitted |
A query component contains parameter text rather than a complete web address. For a normal URL, isolate the text after the question mark and before any fragment. Query-to-JSON accepts an optional leading question mark, while generated query output never includes one. You can therefore add the appropriate delimiter when the result is inserted into a larger URL.
Convert data with Query String Parser
- Choose a direction. Select query-to-JSON when inspecting an existing component, or JSON-to-query when building one from a flat object.
- Paste the supported input and run the conversion. For query-to-JSON, paste only the query component. For JSON-to-query, use a flat object containing accepted scalar values or arrays of those scalars. Keep the pasted input within the 200,000-character limit.
- Inspect the structure and encoding. Check repeated names, single occurrences, empty values, null serialization, reserved characters, and Unicode escapes. Confirm that any arrays contain only values permitted by the selected direction.
- Copy and validate the result. Use the output in the intended URL, request body, fixture, or test only after checking it against the receiving API’s rules for duplicates, nulls, types, and omitted values.
Following the sequence in this order makes the conversion rule visible before the data reaches an application. It also prevents a full URL, signed address, or unsupported nested object from being mistaken for a simple query-component conversion.
Read repeated, empty, and encoded values
The most important output decision is whether each parameter name appeared once or more than once. A single occurrence remains a JSON string, while repeated names become arrays in encounter order. For example, tag=a&tag=b produces a JSON array containing a and b, whereas tag=a remains the string a. The parser does not perform type inference, so page=2 becomes the JSON string "2", not a JSON number.
| Input or situation | Defined behavior |
|---|---|
| Repeated parameter name | Every occurrence is retained in an array in encounter order. |
| Single parameter occurrence | The value remains a string, preserving the source’s single-versus-repeated distinction. |
| name= | The empty value is preserved rather than discarded. |
| Plus sign used for a space | Query-to-JSON treats it as a space; generated query data serializes a space as a plus sign. |
| Literal plus sign | Generated values percent-encode it as %2B so it is not confused with a space. |
| Ampersands, equals signs, and other reserved characters inside values | They are percent-encoded instead of acting as parameter separators. |
| Unicode characters | They are represented through UTF-8 percent encoding. |
| Optional leading question mark | Query-to-JSON accepts it, but generated query output is returned without one. |
These rules follow the browser-compatible URLSearchParams model. The MDN URLSearchParams reference and the WHATWG URL Standard describe the underlying parsing and application/x-www-form-urlencoded serialization behavior.
Build a query string from flat JSON
For JSON-to-query, begin with one JSON object whose values are accepted scalars or one-dimensional arrays of accepted scalars. An object such as {"page":"2","active":true,"note":null,"tag":["a","b"]} demonstrates the supported shape without introducing nesting.
- Strings become encoded form values.
- Finite JSON numbers become their textual forms.
- Booleans become the text true or false.
- null becomes an empty parameter value.
- Arrays of scalars become repeated parameter occurrences in array order.
- Empty arrays are omitted because they contain no value to append.
Nested objects and nested arrays are rejected. Query strings have no universal nested-data representation: bracket names, dotted names, indexed names, and embedded JSON are competing conventions. Flattening a nested object automatically could therefore produce data that looks valid while communicating something different to the receiver.
Type distinctions also narrow when data moves onto the wire. A parsed query value remains text because the query format does not declare a JSON type. Likewise, a JSON number is serialized as text, although the receiving framework may apply schema-specific coercion. Do not expect the parser to convert a numeric-looking string into a number automatically.
Separate query components from complete URLs
Query String Parser does not validate a complete URL, hostname, path, fragment, signature, or authorization policy. If a full URL is pasted, its path can be mistaken for part of a parameter name. When you need URL-component validation, isolate the address with the URL Parser before passing only its query component to Query String Parser.
Sorting or rebuilding query parameters can also invalidate a signed URL or change a cache key. A signature may cover parameter order, duplicate occurrences, percent-escape spelling, and the choice between a plus sign and %20. Preserve the original serialized bytes when canonicalization rules are unknown. When a protocol defines a canonical order or signature algorithm, use that protocol’s official encoder rather than relying on a general-purpose converter. The guide How to Parse Query Params Without Breaking Signatures provides a focused explanation of that boundary.
Observe the input limit and privacy boundary
The current tool bounds work at 200,000 pasted characters. Larger input is outside the supported working limit, so split the task only when doing so will not alter parameter order, duplicate occurrences, or other protocol-sensitive details.
Conversion and clipboard writes stay in the browser. No query text, JSON, token, identifier, or URL is uploaded. Local processing does not make sensitive URL data harmless, though: query strings can be retained by browsers, history systems, analytics, proxies, referrers, and server logs. Avoid placing secrets in URLs, and redact identifiers or other sensitive values before sharing converted output.
Diagnose mismatches before integration
If the conversion looks correct but the receiving application behaves differently, compare its expectations with the parser’s explicit rules rather than changing values at random.
- Type mismatch: A query value such as 2 remains the JSON string "2". Confirm whether the server performs schema-based coercion.
- Duplicate mismatch: The tool preserves every occurrence, but a framework may keep the first value, keep the last, always create arrays, or split comma-separated content.
- Empty-value mismatch: Parsed empty values are preserved, null becomes an empty value during building, and empty arrays are omitted. Check each rule against the receiver.
- Nesting mismatch: Use the exact bracket, dotted, indexed, or embedded-JSON convention required by the application instead of asking the parser to guess.
- Signature mismatch: Preserve the original query bytes or use the protocol’s official encoder whenever canonicalization is required.
The dependable result comes from matching both sides of the conversion: the tool’s form-urlencoded rules and the receiving application’s documented contract. Validate repeated names, empty values, scalar treatment, and parameter order before using the output in production data.