URL Query String Parser
Paste a query string, or a whole URL, and get every parameter decoded in a table and as JSON. Repeated parameters become arrays, “+” can be read as a space as HTML forms do, and bracket notation such as filter[brand]=stride or size[]=42 is combined into nested objects the way PHP and Rails read it.
- Runs in your browser
- No sign-up
- Free to use
| # | Name | Value |
|---|
How to use URL Query String Parser
- Paste a query string or a complete URL.
- Choose how to read “+” and bracket keys.
- Read the decoded parameters in the table.
- Copy or download the JSON.
URL Query String Parser features
Decoding
Percent-encoding and form-encoded spaces decoded.
Repeated keys
Collected into arrays in the JSON.
Nested keys
a[b][c]=1 and a[]=1 combined into objects and lists.
Empty values
Parameters without “=” are kept and marked.
Tolerant
Invalid percent sequences are left as written instead of failing.
Private
Runs in your browser.
When to use URL Query String Parser
- Inspecting what a form or link submits.
- Converting query parameters into JSON for an API test.
- Debugging filters and pagination in web apps.
- Reading tracking parameters in marketing links.
URL Query String Parser FAQ
Is “+” a space?
In query strings produced by HTML forms (application/x-www-form-urlencoded), yes. In RFC 3986 paths and some APIs, “+” is a literal plus. Untick the option to keep it.
How are repeated parameters handled?
Their values are collected into an array, in order.
What are bracket keys?
A convention used by PHP, Rails and many frameworks: size[]=42 builds a list, filter[brand]=x builds an object. Untick the option to keep keys as written.
What happens with a parameter that has no “=”?
It is kept with an empty value and marked as having no value.
Does it decode the fragment?
No. Everything after # is not part of the query and is ignored.
Is the data sent anywhere?
No.
Query strings are a tiny data format
The query string, everything between ? and # in a URL, is how browsers and clients pass parameters to a server. It looks simple, name=value pairs joined by ampersands, but several conventions layer on top, and different servers read the same string differently.
Encoding is the first layer. Characters outside a safe set are percent-encoded, and HTML forms additionally write spaces as plus signs. Decoding with the wrong rule turns “C++” into “C ” or leaves “dark+blue” unreadable, which is why the plus handling is an option here.
Structure is the second. Plain query strings have no notion of lists or objects, so frameworks invented conventions: repeating a key, or writing brackets after it. PHP and Rails turn size[]=42&size[]=43 into a list and filter[brand]=stride into an object. Showing the nested result helps predict what your server will receive.
Seeing the parameters as JSON makes them easier to compare, store or reuse in an API request. The parser keeps the order of parameters and never drops values, so nothing is lost on the way.