Network/HTTP
URL Parser
Break a URL down into its parts — protocol, host, port, path, query parameters, fragment.
A URL is made of several parts — protocol, host, port, path, query parameters, and a fragment — that are easy to mix up when reading a long link. This tool breaks a URL down into those parts and shows each one separately.
How to use it
- Paste any URL and it's split into protocol, host, port, path, query parameters, and fragment (#) instantly.
- Query parameters are listed as separate key-value pairs, even when there are many or they repeat.
- The port is shown explicitly even when the URL doesn't specify one (in which case the protocol's default applies — 80 for HTTP, 443 for HTTPS).
Common uses
- Quickly reading a long link cluttered with dozens of tracking parameters (utm_*, ref, fbclid, and so on).
- Checking exactly which host and port a link from someone else will actually open.
- Debugging redirects or malformed URLs in code — you can see exactly which part differs from what's expected.
Things to keep in mind
The fragment (the part after #) is never sent to the server — it's a purely client-side part of the URL the server never even sees.
Hosts with non-ASCII characters (Cyrillic, CJK) are actually transmitted over the network in punycode (xn--...), even when the browser's address bar shows plain letters.
Article about this tool: URL breakdown: what parts make up a web address
Frequently asked questions
What's the difference between the "host" and "origin" of a URL?
The host is just the domain and port (example.com:8080), while the origin also includes the scheme (https://example.com:8080) — two URLs must match on all three to share the same origin.
Why does the parsed path sometimes look different from what I typed?
Browsers and parsers normalize URLs — collapsing "./" and "../" segments, decoding some percent-encoded characters, and adding a trailing slash to a bare domain — so the parsed result reflects the resolved, canonical form.
Does parsing a URL here send it anywhere?
No. Parsing happens entirely in your browser using the native URL API — nothing is sent to a server.
What is userinfo in a URL, and why is it dangerous?
The <code>username:password@</code> part before the host is meant for credentials, but attackers use it to disguise phishing links: <code>https://accounts.google.com@evil.com/</code> actually leads to evil.com, not Google.
Why does the host in some URLs look like a string of gibberish starting with xn--?
That's punycode encoding for internationalized domain names (IDN) — a way to represent a domain with Cyrillic, CJK, or other non-ASCII characters in a format compatible with the older DNS system.