Parse a Query String Into a Parameter Table

Look at a real-world link and the part after the question mark quickly becomes unreadable: https://shop.example.com/search?q=running%2Bshoes&category=men%2Ffootwear&utm_source=newsletter&color=blue&color=red&page=2. Buried in that string are the search term, a category, a campaign tag, two colour selections, and a page number — all percent-encoded and jammed together. A query string parser pulls them apart into a clean, decoded key/value table so you can read, debug, and reuse them in seconds.

This guide explains what a query string is, how parameters are encoded, and how to parse one correctly — including the edge cases (repeated keys, plus signs, and malformed encoding) that trip up a naive split.

What Is a Query String?

A query string is the part of a URL that comes after the ? character. It carries data to the page as a series of key/value pairs, each separated by an &. In the URL https://example.com/search?q=shoes&page=2, the query string is q=shoes&page=2, which holds two parameters: q with the value shoes, and page with the value 2.

Everything before the ? — the scheme, host, and path — is the base URL: the address of the actual resource. The query string modifies what that resource does or returns. Anything after a # is the fragment, which the browser handles locally and the server never sees.

How Query String Parameters Are Encoded

URLs can only safely contain a limited set of characters, so anything outside that set is percent-encoded: each byte is written as a % followed by two hexadecimal digits. A space becomes %20, a forward slash becomes %2F, and an ampersand inside a value becomes %26 so it is not mistaken for a separator.

There is also a second, older convention from HTML form submissions: in application/x-www-form-urlencoded data, a literal space is written as a + rather than %20. That is why q=running+shoes should be decoded to running shoes. A correct parser applies this "+ means space" rule before percent-decoding, which is exactly what this tool does (and you can toggle it off when you need the literal plus sign).

How to Parse a Query String, Step by Step

1. Separate the base URL from the query

Split the URL at the first ?. Everything to the left is the base URL; everything to the right (up to any #) is the query string. The parser shows the protocol, host, and path so you can confirm you are pointed at the right resource.

2. Split the query into pairs

Break the query string on & to get the individual key/value pairs. Some legacy systems use a semicolon as the separator instead, so a robust parser accepts both.

3. Split each pair on the first equals sign

Each pair splits into a key and a value at the first =. Splitting on the first equals matters: a value can legitimately contain an encoded equals sign, and you do not want to lose it. A pair with no equals at all — such as ?debug — is a valueless flag, and a good parser preserves it rather than dropping it.

4. Decode the key and the value

Apply the "+ means space" rule, then percent-decode both the key and the value. Decode them after splitting, never before — otherwise an encoded %26 or %3D inside a value would be misread as a separator and corrupt the result.

5. Handle repeated keys

A key can legitimately appear more than once, as in color=blue&color=red. You can either group those into a single key with a list of values, or keep them as separate rows. This tool lets you choose, and reports how many keys were repeated.

Common Mistakes When Parsing Query Strings

• Decoding before splitting. Decode each token after you split on & and =, or encoded separators inside values will break the parse.
• Ignoring the "+" rule. Treating + as a literal plus instead of a space mangles form-submitted values.
• Dropping repeated keys. Keeping only the last color value silently loses data; group or list them instead.
• Splitting on every equals sign. Always split on the first equals so encoded equals signs in the value survive.
• Crashing on malformed input. A lone % is invalid percent-encoding; a resilient parser flags it instead of throwing an error.

When You Need a Query String Parser

Decoding parameters by hand is slow and error-prone. A parser is invaluable when you are:

• Debugging campaign tracking — confirming that utm_source, utm_medium, and utm_campaign are spelled and cased correctly before a launch.
• Auditing SEO and analytics — checking which parameters create crawlable URL variants or fragment your analytics reports.
• Reverse-engineering an API or redirect — reading exactly what data a request carries.
• Filing a bug report — turning a giant, encoded URL into a readable table you can paste into a ticket.