CruxDevCruxDev Tools Prompts
dev Utility • Zero-Server Privacy • 100% Client-Side

Query String Parser & Builder

Split any URL into base, path, hash, and decoded query parameters — see the JSON form of every parameter.

Overview

Break a URL into its base address, fragment, and query parameters, with each parameter's decoded value shown in a table and an exportable JSON object. Parsing uses the browser's URL parser, so the results match what server frameworks and the URL standard actually see.

How It Works

Paste a complete URL, including the scheme, into the input. The tool shows the base URL (origin plus path) and fragment, then a table of every query parameter with its decoded value, with empty values marked explicitly. Below the table, a JSON object of all parameters regenerates live. An invalid input is flagged with a message reminding you to include the scheme such as https://.

Step-by-Step Usage Guide

  1. Paste the full URL, scheme included, into the input field.
  2. Read the base URL and fragment cards above the table.
  3. Inspect each parameter row; values are already decoded.
  4. Copy the JSON object below the table for use in code or tests.

Technical Specifications & Standards

The parser delegates to the URL constructor and URLSearchParams, which implement the WHATWG URL standard rather than naive string splitting. Three behaviors follow. First, values are percent-decoded for you: %20 sequences arrive as spaces, and a plus sign is decoded as a space too, because URLSearchParams follows the application/x-www-form-urlencoded convention. Second, repeated keys are preserved: the table shows one row per occurrence in order, so tags[]=css and tags[]=tools appear as two rows. The JSON export, however, is built with Object.fromEntries, which keeps only the last value of a repeated key, so round-tripping repeated parameters through the JSON loses the earlier ones. Third, a parameter with no equals sign, like ?flag, parses as an empty value rather than true. The fragment is shown separately and is never part of the parameter table, matching how servers receive URLs: everything after the hash stays in the browser.

Targeted Use Cases

  • Debugging an outbound link by seeing exactly which parameters it carries.
  • Documenting an API's query parameters from a captured request URL.
  • Turning a marketing URL's UTM parameters into a tidy JSON object.
  • Checking whether special characters in a value were encoded correctly.

Notes & Gotchas

  • Include the scheme when pasting; a bare domain fails the URL constructor.
  • Remember repeated keys collapse to the last value in the JSON export; read the table for the full list.
  • Expect plus signs to decode as spaces; re-encode deliberately if a value legitimately contains a plus.
  • Do not paste URLs containing secrets into shared screenshots; the values are shown in full.

Frequently Asked Questions

Why is the plus sign in my value shown as a space?

URLSearchParams follows the form-urlencoded convention where plus means space. If the original value truly contains a plus, it should have been encoded as %2B, and then it survives as a plus here.

Why does the JSON export lose my repeated parameters?

The JSON is built as a plain object, and an object can hold one value per key, so the last occurrence wins. The table above it shows every occurrence; merge repeated keys into arrays yourself if you need them.

Where did the text after the hash go?

Everything after the hash is the fragment, which browsers never send to servers. The tool shows it in the Fragment card but deliberately keeps it out of the parameter table.

Does it validate parameter names or values?

No. It reports exactly what the URL contains, decoded. Validation of allowed keys or formats belongs to the application that consumes the URL.