URL Parser

Paste a URL and see every part of it broken out: scheme, host (split into subdomain / domain / TLD, with IPv4 / IPv6 / IDN detection), port, path segments, query parameters, and fragment. Tweak any field and the rebuilt URL updates live. Pure client-side, no upload, no tracking.

Try:
How URL parsing works here
  • The parser follows RFC 3986: scheme, then //, then userinfo (optional user:pass@), host, :port, path, query, fragment.
  • Hosts are categorised: IPv4 (e.g. 192.0.2.1), IPv6 bracketed (e.g. [2001:db8::1]), or a DNS name. DNS names that contain a xn-- label are flagged as IDN (Internationalised Domain Name in punycode form).
  • Hosts in private / loopback ranges (RFC 1918 IPv4, ::1, link-local fe80::/10, ULA fc00::/7) are flagged in the breakdown.
  • Ports are mapped to their common service name when known — 22 → SSH, 5432 → PostgreSQL, 27017 → MongoDB, and so on. A port that doesn't match the scheme's default is flagged.
  • Path segments and query keys are shown decoded (UTF-8). The original encoded form is preserved for round-tripping.
  • "Looks phishy" fires when (a) userinfo is present, (b) a query parameter looks like password= / passwd= / token=, or (c) the fragment looks like a login page anchor. It's a heuristic, not a verdict.
  • "Canonical" rebuild lowercases scheme + host, strips the default port (e.g. :443 on https://), and sorts the query alphabetically.
  • Nothing is uploaded. The whole thing runs in your browser.

About this tool

URL Parser decomposes any URL into its component parts — scheme, user info, host, port, path, query string, fragment — and decodes percent-encoded characters in each part. It also parses the query string into a key/value map, handles duplicate keys (they become arrays), and lets you copy any part to the clipboard. The parser follows the WHATWG URL standard, which is the same algorithm browsers use in the address bar — so what you see is what the browser will see when it navigates to the URL.

When to use it

  • Inspecting a long URL with many query parameters before sharing it in a ticket or a chat
  • Debugging a redirect by seeing how the path and query change across hops
  • Decoding a percent-encoded URL to see the original characters
  • Extracting specific parameters from a URL for use in a script

When not to use it

  • You need to fetch the URL — this tool parses, it does not request. Use curl or a browser to fetch
  • You need to construct a URL safely — use the URL Builder tool on the site, which percent-encodes components correctly
  • You need to follow redirects — the parser shows the URL you gave it, not the final URL after redirects

Frequently asked questions

What standard does it follow?

The WHATWG URL standard, which is the same algorithm modern browsers use. URLs that the parser accepts will navigate correctly in Chrome, Firefox, Safari, and Edge. Legacy RFC 3986 quirks (such as a path that starts with a double slash being treated as protocol-relative) are handled the same way the browser handles them.

What happens with non-ASCII characters in the URL?

The parser preserves the percent-encoded form for the canonical representation, and shows the decoded form alongside so you can see the original characters. The two are equivalent — the browser will treat them as the same URL.

← Back to the homepage · More guides · More from the blog