Paste a web address (or just the part after the question mark) and this tool breaks the query string into a tidy list of names and values. It also decodes things like %20 and + back into spaces, so each value is easy to read. Everything runs in your browser.
About this query string parser
The query string is the part of a web address after the ? — a set of name=value pairs joined by & that pass information to a page, like a search term or a page number. This query string parser splits that text into a clean, readable list. You can paste a whole URL or just the query part; the tool ignores anything before the ? and after a #, then decodes percent-codes and plus signs so each value reads naturally. It is handy for debugging links, checking tracking parameters or understanding an API call. The parsing is done in your browser.
Frequently asked questions
- Can I paste a full URL?
- Yes. The tool automatically finds the part after the ? and ignores everything before it, as well as any #section at the end.
- Does it decode %20 and + signs?
- Yes. Percent-codes like %20 and plus signs are turned back into the spaces and characters they represent.
- What happens with a name that has no value?
- It is listed with an empty value, so flags like ?debug still show up in the results.
The Anatomy of a URL Query String
The query string convention originates from the early days of the Common Gateway Interface, where web servers needed a standardized way to pass user input from HTML forms to backend scripts. According to the original specifications, parameters are appended to the end of a uniform resource locator following a single question mark character. Multiple parameters are concatenated using ampersand characters, establishing a strict sequence of key and value pairs. Modern browsers and web servers adhere to these boundaries to ensure that data sent from a client interface reaches the server application intact.
Because standard uniform resource locators can only transmit a limited subset of ASCII characters safely, query strings rely on percent-encoding to represent spaces, punctuation marks, and non-latin characters. A special translation scheme replaces unsafe bytes with a percent sign followed by a two-digit hexadecimal code representing the ASCII or UTF-8 byte value. In addition, legacy form submission standards historically converted space characters into plus signs instead of percent codes. Browsers automatically apply these transformations during transmission, requiring tools on the receiving end to reverse the encoding before the data can be processed.
A frequent error developers make is failing to encode reserved characters such as ampersands, question marks, and equals signs when those characters appear inside a parameter value. Because the parser splits keys and values strictly at every ampersand and equals sign, an unescaped delimiter inside a value will prematurely terminate the current pair and corrupt the remaining parameters. Another common oversight involves forgetting that parameter names and values are case-sensitive by convention, meaning that identical keys with different capitalization will be treated as entirely separate variables by the server.