Paste a URL or query string. Get a clean table of decoded key/value pairs. Works with form-encoded and percent-encoded values, repeated keys, and array notation.
The query string is the part of a URL that comes after the ? and before any # fragment. It carries parameters as key=value pairs separated by &. Both keys and values are URL-encoded — so a value containing a space, comma, or non-ASCII character appears as percent-encoded bytes.
The query-string format allows the same key to appear multiple times. ?tags=a&tags=b&tags=c is three values for the same key. Different frameworks handle this differently: Express.js parses it as an array, PHP turns it into an array if the key ends with [], Ruby on Rails accepts both syntaxes. The standard URLSearchParams API gives you all values via .getAll(key).
In a query string, a space can be encoded as %20 or + — both are accepted. The + form is the legacy convention from HTML form submissions (application/x-www-form-urlencoded). Both this parser and the standard URLSearchParams handle either correctly. In a path component (before the ?), + is literal and only %20 works as a space.
Use this tool when you’re reading server logs and want to understand what a complicated query string actually meant; when you’re testing an API and want to verify which parameters a client sent; when you’re analyzing a tracking link and want to see UTM parameters in plain text; when you’re looking at a JavaScript app’s URL hash routing and need to see the deep-linked state.
A query string looks like one blob of text, but it’s a sequence of well-defined pieces. The parser above splits it along these boundaries — here’s what each part is and which standard governs it:
| Part | Role | Rule / convention | Example |
|---|---|---|---|
? delimiter |
Marks the start of the query — everything after the first ?, up to a # |
RFC 3986 §3.4 (the query component) | ?id=102 |
| Key | The parameter name; percent-encoded if it contains reserved or non-ASCII characters | form-urlencoded convention (WHATWG) | sort |
= binder |
Separates a key from its value | form-urlencoded convention | sort=asc |
| Value | The parameter’s data, percent-encoded; may be empty | Decoded by the parser to readable text | caf%C3%A9 → café |
& separator |
Divides one key/value pair from the next | form-urlencoded convention | id=102&sort=asc |
+ / %20 |
Both represent a space in a query; + is the form-encoding legacy form |
WHATWG form-urlencoded (+) vs RFC 3986 (%20) |
q=a+b |
[] / repeated keys |
A key appearing more than once, or with [], signals a list of values |
Framework convention (PHP, Rails); not a standard | tags[]=a&tags[]=b |
Note the split ownership: the ? delimiter is defined by RFC 3986, but the internal key=value&key=value structure — and + for a space — comes from the application/x-www-form-urlencoded serializer in the WHATWG URL Standard, not RFC 3986. The bracket and repeated-key array forms are framework conventions on top of that, which is why different back ends read them differently.
See also: How to parse a query string in JavaScript — a step-by-step guide with runnable code.
See also: How to capture incoming HTTP request parameters — a step-by-step guide with runnable code.
? and running up to a #. rfc-editor.org/rfc/rfc3986 §3.4key=value&key=value serialization and the +-for-space convention that URLSearchParams follows. url.spec.whatwg.orgcaf%C3%A9 decodes back to café. rfc-editor.org/rfc/rfc3629Honest scope: only the ? query delimiter is defined by RFC 3986. The key=value& pair structure and +-for-space are the WHATWG form-urlencoded convention, and array forms like tags[] are framework-specific — there’s no single standard for how repeated keys become a list.
It takes the part of a URL after the ? and splits it into its individual key/value pairs, decoding each one so you can read the values. Paste a URL or a bare query string above and you get a clean table — useful for inspecting tracking parameters, API calls, or a link that isn’t behaving.
The & character separates one key/value pair from the next, and = binds a key to its value — so ?a=1&b=2 is two parameters. The parser above handles this for you, including edge cases like missing values.
That’s a common convention for passing several values under one key. Many back-end frameworks (PHP, Rails, and others) read tags[]=alpha&tags[]=beta as an array. The parser groups repeated keys so you can see all the values at once.
It depends on the receiving framework — some keep only the last value, some collect them into an array, some keep the first. There’s no single rule, which is exactly why viewing them in a parser helps: you can see every occurrence rather than guessing which one wins.
A key with no value (like ?debug&page=2) is shown with an empty value. Whether the server treats that as an empty string or a boolean flag is up to its own logic — the parser just shows you faithfully what’s in the string.
Both are decoded to a space. In a form-encoded query string a + means a space, and %20 means a space everywhere. The parser normalizes both so the values you see are the real, decoded text.
Yes — both the key and the value are percent-decoded, so an encoded key like %3Ffield is restored correctly and mapped to its value. Everything runs in your browser.
Faceted filters append every selected option — size, colour, price, brand — as its own parameter, so the query grows quickly. That’s manageable for the store but can create crawl-budget and duplicate-URL issues; our faceted-navigation guide covers the SEO side.
The parser gives you a clean key/value breakdown you can copy. From there the pairs map directly onto a JSON object — each key becomes a property and each decoded value its value. Repeated keys become an array, matching how most back ends interpret them.
No. This parser runs entirely in your browser with JavaScript — the URL you paste never leaves the tab, so it’s safe for links that contain tokens or session IDs, and it works offline.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.