URL parser

Paste a URL and this tool splits it into its components, the way a browser sees it internally: protocol, username, password, host, hostname, port, pathname, hash, and origin. Query parameters get their own table, decoded and listed key by key, so ?a=1&b=hello%20world shows up as a: 1 and b: hello world instead of one long encoded string.

Why not just read the URL by eye?

Because URLs are easy to misread. A colon, an @ sign, or a stray slash in the wrong place changes what a URL actually points to, and browsers resolve that ambiguity with a formal set of rules rather than guesswork. This tool uses the browser’s own built-in URL parser instead of a hand-written regular expression, so it splits the string exactly the way the WHATWG URL Standard defines and matches what your browser would actually do with it. If what you paste isn’t a valid URL, it says so rather than guessing at a partial result.

That built-in parser is also why the userinfo section (user:pass@host) and the port come out cleanly separated from the hostname. A URL like http://user:pass@evil.com@real-site.com/ is a classic phishing trick precisely because it’s hard to parse correctly by eye. Running it through the same code path a browser uses shows you real-site.com as the actual host, with user:pass@evil.com as the userinfo, which is exactly what you want to see before clicking anything.

Does the URL I paste get sent anywhere?

No. Parsing happens entirely in your browser. A URL you paste here, even one carrying an auth token in the query string or credentials in the userinfo section, never leaves your machine.

What do people use this for?

Checking a redirect URL before trusting it, reading an OAuth callback with a dozen query parameters, confirming which port an API base URL actually points to, or working out why a link with embedded credentials isn’t behaving the way you expect. See MDN’s URL API reference for the properties this tool reads, and MDN’s guide to URL structure if some of these terms are new.