URL Parser

By · Updated

Paste any URL and see the breakdown: scheme, host, port, path, query parameters, fragment. Duplicate query keys are preserved. Built on the WHATWG URL parser — same one your browser uses.

URL parser

Component Value
Protocol https:
Username
Password
Hostname shop.example.com
Port 8443
Host shop.example.com:8443
Origin https://shop.example.com:8443
Pathname /products/red-shoes
Search ?size=42&color=red&utm_source=newsletter
Hash #reviews
Full URL https://shop.example.com:8443/products/red-shoes?size=42&color=red&utm_source=newsletter#reviews

Query parameters (3)

Key Value
size 42
color red
utm_source newsletter

Anatomy of a URL

https://shop.example.com:8443/products/red-shoes?size=42&color=red#reviews
└─┬─┘   └────────┬───────┘ └┬─┘└──────┬──────┘└────────┬─────────┘└──┬───┘
scheme       hostname     port     pathname          search        hash

The five pieces, in the order they appear: scheme (always followed by :), authority (host plus optional port), path, query string (prefixed by ?), and fragment (prefixed by #). Everything before the fragment is sent to the server; the fragment stays on the client.

The browser's URL constructor follows the WHATWG URL spec, which is the modern living-standard replacement for RFC 3986. The two agree most of the time; where they differ, every modern browser follows the WHATWG rules. This parser uses the same constructor, so what you see here is what your code will see.

Frequently asked

What's the difference between host and hostname?
Hostname is the domain alone — shop.example.com. Host is the same domain plus the port if one was specified — shop.example.com:8443. When the URL uses the default port for the scheme (80 for http, 443 for https), the port is omitted from both fields. Use hostname when you want the domain; use host when you're reconstructing the address as it appears in HTTP headers like Origin.
Why is the origin different from the full URL?
Origin is the security boundary your browser uses — scheme + host + port and nothing else. Two URLs share an origin if those three pieces match, regardless of path, query, or fragment. The same-origin policy that gates cross-window communication, cookies, and CORS preflights operates on origins, not URLs.
Does the parser handle URLs with non-ASCII characters?
Yes. Internationalised domain names (xn-- punycode) are decoded back to their Unicode form in hostname; non-ASCII path and query characters are decoded into the percent-encoded form they actually transmit as. If you paste a 'pretty' URL with raw Unicode characters, the parser normalises it the way a browser would.
What happens if my URL has duplicate query keys?
Duplicate keys are legal in URLs and the parser preserves them. The table view shows each occurrence as its own row, in order. This matters when you're debugging analytics tags or filter UIs that intentionally repeat a key — casting to a Map or plain object loses one of the values.
Why doesn't my URL parse?
Almost always because the scheme is missing. The WHATWG parser (which this tool uses) requires a scheme — example.com/foo isn't a valid URL on its own. Add https:// in front and it parses. The other common failure is invalid percent-encoding in the input — %ZZ or %2 with nothing after it.
Is this safe for sensitive URLs (auth tokens, internal links)?
Yes. The parser runs entirely in your browser — the URL you paste never reaches a server. You can verify this by opening DevTools, switching to the Network tab, and confirming there's no outbound request when you parse something.
All tools →