Query String Parser

In the Key and Value table each occurrence stays on its own row, so nothing is lost. In the JSON view a key that appears more than once is grouped into an array of its values in the order they were written, while a key that appears once maps to a plain string.

Yes. When parsing to JSON both keys and values are percent-decoded, so %20 becomes a space and %26 becomes an ampersand. A plus sign is also converted to a space, which matches how browsers historically read form-encoded query strings.

A bare segment with no equals sign, such as flag, is parsed as that key with an empty string value. The key is preserved rather than dropped, and in the table its value column simply reads as empty.

You can include a leading question mark and it is stripped automatically, so a=1&b=2 and ?a=1&b=2 parse identically. It does not split a whole URL for you, so paste only the query portion after the question mark rather than the scheme and path.

When you build a query from pairs, keys and values are percent-encoded and a space becomes %20 rather than a plus sign. Pairs are joined with an ampersand, and any row whose key is empty is skipped so you never emit a dangling equals sign.

Only the first equals sign in a segment splits the key from the value, so a segment like token=a=b=c parses to the key token with the value a=b=c. This mirrors how servers read tokens and base64 values that contain their own equals characters.

No. Pairs are read strictly left to right and kept in that order, both in the table and in the JSON object. Order can matter for signed URLs and some APIs, so the tool never sorts or reshuffles your parameters.

If a value contains an invalid percent escape that cannot be decoded, the tool falls back to the plus-normalized text for that piece instead of throwing an error, so you still get a readable result rather than a crash.

No. Parsing, decoding and building all run locally in your browser, so URLs that carry tokens, ids or search terms never leave your device.