About URL Parser & Query Inspector
Parsing runs through the browser's own URL implementation, so the breakdown matches what a browser will genuinely do with the link rather than approximating it. Parameters are shown decoded, which is how a value that was double-encoded upstream gives itself away.
Parse any URL to see every query-string parameter decoded in a table, along with the protocol, host, port, path and hash. It is built on the browser's own URL engine, so it matches real behaviour.
A URL packs a lot of structure into one string. This parser breaks any URL into its parts — protocol, username and password, hostname, port, path, fragment and origin — and lists every query-string parameter in a decoded table so you can see exactly what a link carries. Paste a URL with or without a scheme; if you omit it, https:// is assumed.
It is built for the URLs that go wrong: a redirect chain that quietly drops a parameter, an analytics tag with a duplicated key, an OAuth callback whose state value arrived double-encoded. Listing every parameter separately is usually enough to show which one is malformed.
Reading a hostname correctly is a security skill, not just a debugging one. Hostnames resolve right to left: in shop.example.co.uk the top-level domain is uk, the registered domain is example.co.uk, and shop is a subdomain. Phishing exploits exactly this — example.com.attacker.net is a page on attacker.net, with the familiar name placed first because that is what a hurried reader anchors on. Seeing the host isolated from the rest of the URL makes the real registrable domain obvious.
The fragment behaves unlike every other component and it explains a recurring class of confusion. Everything after the hash is handled entirely by the browser and is never transmitted to the server, so it appears in no access log, no referrer header and no server-side analytics. When a value is visible in the address bar but absent from the backend, being in the fragment rather than the query string is almost always why.
Tracking parameters are worth recognising on sight. Anything beginning utm_ is campaign attribution added by the sender rather than required by the destination, and fbclid, gclid and similar are click identifiers appended by a platform. All of them can normally be stripped without changing which page you land on, which makes a shared link shorter, cleaner and less revealing about where the recipient found it.
Common use cases
- Untangling a long tracking URL to see which parameters it carries
- Debugging why an API rejects a request built from query params
- Checking exactly what a redirect or callback URL is passing along