Query Parameter Parser — Free Online Tool

Parse URL query strings into structured key-value tables. Decode percent-encoded values, arrays and nested objects for easier debugging.

Use this free online Query Parameter Parser directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 133+ developer utilities.

What is URL Query Parameter Parser?

A URL query parameter parser extracts the key-value pairs from the query string portion of a URL (the part after ?) and displays them in a readable, structured format. It decodes percent-encoded values (%20 → space, %26 → &), detects array parameters (repeated keys or bracket notation), and shows each parameter on its own row.

  • Automatic decoding: Percent-encoded values (%20, %26, %3D) are automatically decoded to their original characters. Spaces, ampersands, and special characters become readable.
  • Array parameter detection: Detects both styles of arrays: ?color=red&color=blue (repeated keys) and ?tags[]=a&tags[]=b (bracket notation). Shows arrays as grouped items.
  • Nested object support: Handles nested parameters like ?user[name]=John&user[age]=30 and displays them as structured objects.
  • Key-value table display: Shows each parameter in a table with key and decoded value columns. Much easier to read than a raw URL string.
  • Empty and null value handling: Distinguishes between ?key= (empty string), ?key (no value), and missing keys. Shows the exact state of each parameter.

Why use query parser?

Long URLs with many query parameters are unreadable. Percent-encoding makes them worse. This tool breaks them into individual parameters so you can see exactly what data is being sent.

  • Decode cryptic URLs instantly: A URL like ?q=hello%20world%26friends is hard to read. The parser shows q = 'hello world&friends' with all encoding resolved.
  • Debug API requests: When an API call fails, paste the URL to see which parameters are set, which are missing, and whether encoding is correct.
  • Inspect tracking links: Marketing URLs have 5–10 UTM parameters (utm_source, utm_medium, etc.). The parser shows them all in one table instead of hunting through a long URL.
  • Understand OAuth callbacks: OAuth redirect URLs contain state, code, and other parameters. Parse them to see the exact values returned by the authorization server.
  • Verify URL building: If you built a URL programmatically, parse it to confirm all parameters are correct and properly encoded.
  • Runs locally: No upload. URLs with tokens, session IDs, or sensitive parameters stay in the browser.

When to use query parser

Use whenever you need to understand what parameters a URL contains.

  • Debugging API requests by examining which filters, pagination, or search parameters were sent.
  • Analyzing tracking URLs to see UTM parameters, referral codes, or campaign IDs.
  • Inspecting OAuth callback URLs to extract authorization codes, state, or error parameters.
  • Reviewing query strings from server logs, analytics tools, or network traffic to understand user behavior.
  • Verifying that URL-building code correctly encodes and includes all required parameters.
  • Understanding deep links for mobile apps or single-page applications.
  • Learning how query strings work by parsing examples from real URLs.

How to use query parser

Paste a URL or query string, and see parameters in a table.

  1. Paste the URL or query string: Paste a full URL (https://example.com?key=value) or just the query string (?key=value&key2=value2). The tool automatically extracts the query portion.
  2. View the parsed parameters: Each parameter appears in a table row with the key in the left column and the decoded value in the right. Percent-encoding is automatically decoded.
  3. Identify arrays and objects: Repeated keys (color=red&color=blue) are shown as array entries. Nested parameters (user[name]=John) are displayed with bracket notation.
  4. Check for encoding issues: If a value looks wrong (e.g., 'hello%20world' instead of 'hello world'), the parameter was not decoded by the server or was double-encoded.
  5. Copy individual values: Click or select a value to copy it. Useful for extracting tokens, IDs, or other data from long URLs.
  6. Compare with expected parameters: If an API call failed, compare the parsed parameters with the API documentation to see which parameters are missing or incorrect.

Key features

  • Automatic percent-decoding: Converts %20 to space, %26 to &, %3D to =, and all other percent-encoded characters to their original form.
  • Array parameter detection: Detects ?key=val1&key=val2 (repeated keys) and ?key[]=val1&key[]=val2 (bracket notation) and groups them as arrays.
  • Nested object parsing: Handles ?user[name]=John&user[age]=30 and displays as structured nested parameters.
  • Key-value table display: Shows each parameter in a structured table with key and value columns for easy reading.
  • Empty and null value handling: Distinguishes between ?key= (empty value), ?key (no value), and absent keys.
  • Full URL or query string input: Accepts full URLs or just the query string portion (?key=value). Extracts the query part automatically.
  • Copy individual values: Select and copy individual parameter values for use in other tools or API clients.

Common use cases

  • API debugging: Parse API request URLs to see which filters, pagination, or search parameters were sent.
  • Marketing URL analysis: Extract UTM parameters (source, medium, campaign) from tracking links for analytics review.
  • OAuth flow inspection: Parse OAuth redirect URLs to extract authorization codes, state parameters, or error messages.
  • Server log analysis: Parse URLs from access logs to understand what parameters users are sending.
  • URL builder verification: Verify that programmatically built URLs have correct parameters and encoding.
  • Learning and education: Understand how query strings work by parsing real-world URL examples.

Examples

Query strings parsed by this tool.

Simple search query

?name=John%20Doe&page=2&sort=date
name = John Doe
page = 2
sort = date

The %20 is decoded to a space. Each parameter is shown on its own row with the key and decoded value.

UTM tracking parameters

?utm_source=email&utm_medium=newsletter&utm_campaign=summer_sale&utm_content=cta_button
utm_source = email
utm_medium = newsletter
utm_campaign = summer_sale
utm_content = cta_button

All four UTM parameters are displayed in a table. No encoding needed because the values contain only safe characters.

Array parameters (repeated keys)

?color=red&color=blue&color=green&size=large
color = ['red', 'blue', 'green']
size = large

The three color parameters are grouped as an array. The size parameter is a single value.

Special characters in values

?filter=price%3E100%26category%3DBooks&page=1
filter = price>100&category=Books
page = 1

%3E is decoded to >, %26 to &, %3D to =. The filter value is 'price>100&category=Books', not two separate parameters.

OAuth callback URL

?code=abc123xyz&state=random_token_456
code = abc123xyz
state = random_token_456

OAuth authorization codes and state parameters are extracted and displayed clearly.

Technical reference

The query string parsing rules and decoding behavior:

Input format
Full URL (https://example.com?key=value) or query string only (?key=value&key2=value2)
Separator
& separates key-value pairs. ; is an older separator supported by some servers but not recommended
Key-value delimiter
= separates keys and values. If no = is present, the key has no value (e.g., ?debug is key='debug', value=null)
Percent-decoding
Converts %XX to the corresponding character. %20 → space, %26 → &, %3D → =, etc.
Space encoding
Both %20 and + are decoded to space. The tool handles both forms
Array detection (repeated keys)
?color=red&color=blue is parsed as color = ['red', 'blue']
Array detection (bracket notation)
?tags[]=a&tags[]=b is parsed as tags = ['a', 'b']
Nested objects
?user[name]=John&user[age]=30 is parsed as user = {name: 'John', age: '30'}
Empty values
?key= (with =) is an empty string value. ?key (no =) is null or true depending on server
Comparison to hash/fragment
Query string is after ? and before #. Fragment (# portion) is not sent to the server and is parsed separately

Common mistakes to avoid

Assuming + is always a literal plus sign in values

Why it happens: In query strings, + is an alternate encoding for space (from application/x-www-form-urlencoded). If a URL has ?search=hello+world, the parser decodes it as 'hello world', not 'hello+world'. If you wanted a literal +, it should be encoded as %2B. This is a common confusion because + has different meanings in URLs vs. regular text.

How to avoid it: If you see + in a query string, it usually means space. If you need a literal + in a value, encode it as %2B when building the URL. When parsing, understand that + and %20 both decode to space.

Not checking for double-encoded values

Why it happens: If a value is encoded twice, you get %2520 instead of %20 (because %25 is the encoded %). When decoded once, it becomes %20 (the literal characters % 2 0), not a space. This happens when URL-building code encodes an already-encoded value. The result: a parameter that looks correct but has literal %20 instead of a space.

How to avoid it: If parsed values contain literal %20 or other %XX sequences, the URL was double-encoded. Decode the value a second time manually, and fix the URL-building code to avoid double-encoding.

Confusing query string (?key=value) with hash/fragment (#section)

Why it happens: The hash/fragment (# portion) is not part of the query string and is not sent to the server. If a URL is https://example.com?key=value#section, only ?key=value is the query string. The #section is the fragment and is handled by the browser, not parsed from the query. If you parse the full URL including #, the fragment may be treated as part of the last parameter value.

How to avoid it: Separate the query string (? to #) from the fragment (# to end) before parsing. Most URL parsers handle this automatically. If you see unexpected # characters in parsed values, the URL was not split correctly.

Expecting parameter order to be preserved

Why it happens: The HTTP spec says query parameter order is insignificant, so servers and parsers may rearrange them. If you parse ?a=1&b=2 and expect 'a' to always come before 'b', that is not guaranteed. Some servers preserve order, others alphabetize, others use hash table order (unpredictable).

How to avoid it: Do not rely on parameter order unless the API spec explicitly requires it (e.g., for signature calculation). Access parameters by key, not by position.

Treating arrays in different notations as incompatible

Why it happens: Some frameworks expect ?key=val1&key=val2 (repeated keys), others expect ?key[]=val1&key[]=val2 (bracket notation). If you build a URL with one style and the server expects the other, the array may not parse correctly. For example, Express.js supports both, but some frameworks only support one.

How to avoid it: Check the API documentation for the expected array format. If the server does not support bracket notation, use repeated keys. If it requires brackets, add them. The parser shows both styles, but you need to know which the server expects.

Frequently asked questions

How are array parameters handled?

The parser detects two array styles: (1) Repeated keys: ?color=red&color=blue is parsed as color = ['red', 'blue']. (2) Bracket notation: ?tags[]=a&tags[]=b is parsed as tags = ['a', 'b']. Both are shown as arrays in the output. The server framework determines which style is supported.

What is the difference between ?key= and ?key (no equals)?

?key= has an equals sign with no value, so the key has an empty string value ('key' = ''). ?key has no equals sign, so the interpretation depends on the server: it may be null, true (boolean flag), or an empty string. The parser shows both cases and indicates the difference.

Why are some characters like & and = showing up as %26 and %3D?

If & or = appear inside a parameter value, they must be percent-encoded, or they break the query string structure. The parser automatically decodes them. If you see %26 or %3D in the parsed output, the URL was double-encoded (encoded twice). Decode again manually or fix the URL builder.

Can I parse a full URL, or just the query string?

Both. Paste a full URL (https://example.com/path?key=value) and the tool extracts the query string portion (?key=value). Or paste just the query string (?key=value&key2=value2). The domain and path are ignored.

What happens to the hash/fragment (# portion) of a URL?

The hash/fragment (#section) is not part of the query string and is not sent to the server. It is handled by the browser for client-side navigation. The parser ignores the fragment and only parses the query string (? to # or end of URL).

How do I know if a URL was double-encoded?

If parsed values contain literal %20, %26, or other %XX sequences instead of spaces, &, etc., the URL was double-encoded. For example, %2520 (encoded %) decodes to %20 (literal characters), not a space. Decode the value a second time or fix the URL builder.

Can I use this to debug why my API request is failing?

Yes. Copy the request URL from the browser DevTools Network tab, curl command, or server logs. Paste it into the parser to see exactly which parameters are being sent and their decoded values. Compare with the API documentation to find missing, incorrect, or malformed parameters.

References

Privacy and availability

  • Runs entirely in your browser — zero server processing
  • No signup or account required
  • Works offline once loaded
  • Fast, lightweight, no external dependencies
  • Available as a browser extension for Chrome and Firefox