Skip to content
koducathome

URL Query String Parser

Convert URL query strings into JSON and build query strings from JSON, with correct encoding and repeated keys.

How to use this tool

Steps for using the Query String Parser.

  1. Pick a direction: Query → JSON or JSON → Query. The result updates as you type, and keys, values and %XX escapes are colour-coded.
  2. To parse, paste a query string with or without the leading ?, or a whole URL — only the part between ? and # is used, and the base URL is shown in the status bar.
  3. Choose whether + means a space (the HTML form convention), whether bracket keys like user[name] and tags[] become nested objects and arrays, whether 42 and true become numbers and booleans, and whether keys are sorted. Switch to Table to see every parameter decoded next to its raw form, with repeated keys marked.
  4. To build, paste a JSON object and choose how arrays are written: repeated keys (tag=a&tag=b), brackets (tag[]=a), indexes (tag[0]=a) or comma-separated (tag=a,b). Optionally add a Base URL, encode spaces as +, encode brackets or add a leading ?.
  5. Click the round arrow button to swap direction with the result, then Copy, Download or Expand it.

Example

Nested query string to JSON

Query string
?user[name]=Ada+Lovelace&user[langs][]=en&user[langs][]=fr&page=2&tag=a&tag=b
JSON
{
  "user": {
    "name": "Ada Lovelace",
    "langs": [
      "en",
      "fr"
    ]
  },
  "page": "2",
  "tag": [
    "a",
    "b"
  ]
}

Common use cases

  • Reading a long search or filter URL as structured JSON while debugging an API.
  • Building correctly encoded query strings for requests in the API Tester or in tests.
  • Checking how a PHP or Rails-style bracket query will be interpreted by the backend.
  • Converting form submissions (application/x-www-form-urlencoded) into JSON for logs or fixtures.
  • Spotting malformed percent-encoding that breaks a server's parser.

How query strings map to JSON

A query string is a flat list of key=value pairs separated by &. Keys and values are percent-encoded: reserved characters such as &, =, # and non-ASCII text are written as %XX bytes of their UTF-8 encoding, so café becomes caf%C3%A9. When parsing, each pair is split at the first =, then both sides are decoded. A key without = gets an empty string value. Every value is a string — query strings have no numbers, booleans or null — so page=2 becomes "page": "2".

The plus sign is a historical quirk. HTML forms submitted as application/x-www-form-urlencoded encode spaces as +, and URLSearchParams decodes them that way, so the option is on by default. In other contexts, such as some signed URLs or hand-written APIs, a literal + might not have been encoded as %2B; turn the option off to keep it.

There is no official standard for nesting, but the bracket convention used by PHP, Ruby on Rails and the Node qs library is widespread: user[name]=x describes an object and tags[]=a&tags[]=b an array. Numeric indexes like items[0]=x&items[1]=y become an array when they run from 0 without gaps. A key that is repeated without brackets (tag=a&tag=b) also becomes an array. If a key is used both as a plain value and as a nested object, the tool keeps the bracket key flat and warns, rather than silently overwriting data. Malformed percent-encoding — a % not followed by two hex digits, or bytes that are not valid UTF-8 — keeps the raw text and adds a warning.

Building a query string reverses the process with encodeURIComponent, which encodes spaces as %20 (valid everywhere, unlike +). Nested objects become bracket keys, arrays use either repeated keys or [], arrays of objects use indexes (items[0][id]=1), numbers and booleans are stringified, and null, empty arrays and empty objects are skipped because a query string cannot express them. Brackets in keys are left readable by default; servers accept both forms, and you can percent-encode them if a strict client requires it.

Limitations

  • All parsed values are strings; the tool does not guess numbers or booleans.
  • Bracket nesting follows the common PHP/Rails/qs convention; backends with other conventions (e.g. dot notation a.b=1) may interpret keys differently.
  • a[][b]=1 (objects pushed into arrays without an index) is ambiguous and kept as a flat key.
  • When building, null, empty arrays and empty objects are omitted, so a round trip does not restore them.

Frequently asked questions

Should spaces be encoded as + or %20?

Both are understood by form parsers, but %20 is valid in every part of a URL while + only means space in form-encoded data. This tool writes %20 and, when parsing, treats + as a space unless you turn that option off.

Why are numbers in the JSON output strings?

Query strings carry only text. Whether page=2 is a number is decided by the server. Keeping strings avoids changing values like zip codes (01234) or IDs that look numeric.

How do I send an array in a query string?

There are two common styles: repeat the key (tag=a&tag=b), which most frameworks support, or use brackets (tag[]=a&tag[]=b), which PHP and Rails expect. Check what your backend parses and choose the matching option.

What happens with an invalid sequence like %ZZ?

The raw text is kept unchanged and a warning lists the affected keys or values, so you can see exactly where the encoding is broken.

Is this the same as URL-encoding a whole string?

No. This tool encodes each key and value separately and joins them with & and =. To encode or decode a single piece of text, use the URL Encoder.