How URL Parser works
A long URL with a dozen tracking parameters is hard to read and easy to misread. Paste one here and it is broken into its parts — scheme, host, port, path, query string and fragment — with each query parameter listed separately and percent-decoded, so %20 reads as a space and repeated keys are shown as the separate values they actually are. Parsing follows the same WHATWG URL standard browsers use, which means the result matches what the browser itself would do rather than what a hand-written regular expression might guess.
When you would reach for this
Auditing campaign tracking links
Seeing every utm_ parameter laid out separately makes it obvious when a link has duplicated or contradictory campaign values.
Debugging an API request
When a request returns the wrong data, the query string is often the cause — a parameter misspelled, missing or encoded twice.
Understanding a redirect chain
Redirect URLs frequently carry an entire second URL as an encoded parameter. Decoding reveals where the user is really being sent.
Checking a callback or webhook URL
OAuth and webhook URLs pack state, tokens and return paths into the query string. Splitting them apart makes each piece readable.
Using URL Parser
- 1
Paste a complete URL, including the https:// or http:// scheme.
- 2
Read the components panel for the protocol, host, port, path and fragment.
- 3
Check the query parameter table, where each value is shown already decoded.
- 4
Review the path segments list if you are working out how a route is structured.
Which parts of a URL reach the server
Not all of a URL is sent in the request, and knowing which parts are is genuinely useful. The scheme and host determine where the connection goes and appear in the Host header. The path and query string are sent in the request line, which means the server sees them, they appear in access logs, and anything sensitive placed in a query parameter ends up written to disk on every proxy in between — this is why access tokens belong in a header rather than a query string. The fragment, everything after the #, is different: it is handled purely by the browser and is never transmitted. That is what makes fragments suitable for in-page anchors and client-side routing, and it is also why an analytics tool that reads the fragment must run in the browser, since the server has no way to see it. Credentials embedded before the host in the user:password@ form are sent, but they are deprecated and blocked outright by many browsers.
How repeated parameters and encoding are handled
A query string is a flat list of key-value pairs, not a map, so nothing prevents the same key appearing several times — and many APIs rely on this to express lists, as in ?tag=red&tag=blue. Each occurrence is listed as its own row here rather than being collapsed, because collapsing would hide exactly the detail you are trying to inspect. How a server interprets repeats varies: some take the first value, some the last, and some collect them into an array, which is a real source of bugs when a front end and a back end disagree. On decoding, both %20 and + become a space, since the form-encoded convention treats a plus as a space — this is why a genuine plus sign in a value must be sent as %2B, and why phone numbers in query strings so often lose their leading plus.
Worth knowing
- A URL without a scheme cannot be parsed unambiguously; prefix it with https:// if you only have the host and path.
- If a parameter value looks like a URL, run it through the parser again — nested encoded URLs are common in redirects and OAuth flows.
- Never put a token or password in a query string; it lands in server logs, browser history and the Referer header sent to other sites.