ToolMill.io

URL Query String Parser and Builder

Parse URL query strings into readable key/value data and rebuild them when testing links, tracking parameters, filters, redirects, signed URLs, or app state in the browser. It is useful for debugging marketing URLs, API requests, and web-app routing behavior. ToolMill gives you a quick private workspace in the browser instead of making you paste real customer URLs into a remote tool.

Development

Try it

Examples

Simple key-value query string
Input
name=John&age=30&city=New%20York
Output
{"name":"John","age":"30","city":"New York"}
Repeated parameter keys as array values
Input
tag=js&tag=web&tag=tools
Output
{"tag":["js","web","tools"]}

Paste a Full URL or Just the Query String

This parser is useful whether you have a complete link copied from a browser or only the raw part after the question mark. If you paste a full URL, the tool strips everything before the query string and focuses on the parameters. That makes it convenient when you are debugging a shared marketing link, an API callback URL, a redirect target, or a web-app route without manually cleaning the input first.

How Repeated Keys Are Interpreted

Repeated parameters such as tag=js&tag=web are common in filters, faceted search, and analytics tooling. This page keeps those repeated keys and groups the values into an array so you can see that the same parameter appeared more than once. That is helpful when you are checking whether an app is preserving multi-select filters or whether a URL builder accidentally duplicated a parameter.

How URL Decoding Affects the Output

Parsed output often looks different from the raw URL because encoded characters are decoded for readability. %20 becomes a space, and other escaped symbols are converted back into the characters they represent. That is usually what you want during debugging, but it also means the output is an interpreted view of the query string rather than a byte-for-byte copy of the original URL text.

Empty Values, Missing Values, and Bare Flags

Not every parameter has a normal key=value shape. Some URLs include empty values such as utm_term=, and others include bare flags where only the key is present. Those cases can still matter when you are tracing routing behavior, campaign-tagging bugs, or feature flags. Looking at the parsed output helps you see whether a missing value is truly absent or whether it exists as an empty string in the URL.

Common Query String Examples

Typical examples include search filters, pagination, product variants, referral tags, and analytics parameters such as utm_source or utm_campaign. This page is especially useful when a link looks valid at a glance but behaves differently after a redirect, a framework router, or a browser normalizes the address. Reading the parameters in formatted JSON is often faster than visually parsing a long copied URL by hand.

When Parsed Results Differ from Your App

Different frameworks do not always interpret query parameters the same way. Some treat repeated keys as arrays, some use bracket notation for nesting, and some apply custom rules for booleans, flags, or empty values. If the output here differs from what your app shows, the mismatch may be in the framework-specific parser rather than in the URL itself. This page gives you a clean baseline interpretation, but it cannot replicate every app-specific convention.

Privacy and Browser-Local Parsing

Parsing happens locally in your browser. ToolMill does not need to send pasted URLs, campaign tags, signed links, or internal query parameters to a remote service just to inspect them. That makes the tool more comfortable to use when the URL contains customer identifiers, internal routes, temporary tokens, or marketing data you would rather keep in your own browser session.

Limitations and Format Edge Cases

Before You Rely on Parsed Query Parameters

Before changing production links or debugging a live issue, confirm how the real destination handles repeated keys, decoding, blank values, and parameter order. This page is a fast inspection aid, but the final behavior still belongs to the framework, router, or backend that receives the URL.

Why Parsed Results May Differ from Your Application

Frameworks often apply their own rules for arrays, parameter precedence, ordering, or duplicate keys. If the output here differs from what your app does, the likely cause is framework-specific parsing logic rather than a broken URL string. This page shows a generic browser-side interpretation, not your application’s private parser.

How to Interpret Repeated Keys and Empty Values

Repeated keys, blank values, and bare flags can all be legitimate query-string patterns, but different apps interpret them differently. This page helps you inspect the raw structure after parsing; it does not define a universal meaning for duplicate parameters or empty values across every framework.

Query strings do not have one universal application-level convention for arrays, nesting, and typed values. A parameter like filters[color]=blue or ids[]=1&ids[]=2 may be parsed differently by different libraries. Use this tool to understand the raw parameter structure quickly, but confirm framework-specific behavior in the application that ultimately consumes the URL.

Related tools