How to parse a URL
- Paste the URL into the box above. A missing https:// is added for you.
- The components appear immediately in the list below.
- Check the query parameters, which are listed with their values already decoded.
- Look at the path segments if you are working out a routing pattern.
- Press Clear when you are done.
What the parser shows
- Protocol, host, port, path, query and fragment, separated cleanly.
- Every query parameter listed individually with its value decoded.
- The origin, which is what browsers compare for same-origin policy.
- Domain and subdomain split apart for quick reading.
- Path segments listed separately, useful when working out routing.
- A note when credentials are embedded in the URL, with the password masked.
A URL has more parts than people remember
Most URLs look simple until you meet one that is not. A tracking link with fifteen parameters, a redirect chain with a URL nested inside a URL, an API endpoint with a port and a fragment, reading those by eye is slow and error-prone.
Splitting them apart makes the structure obvious: which host is really being contacted, what the path is, and exactly which parameters are being sent with which values.
Parsed the way browsers parse
This uses the browser's own URL implementation, which follows the WHATWG specification. The same code that runs when you type an address into the bar. That matters, because URL parsing has more edge cases than expected and a hand-rolled regular expression will disagree with the browser on some of them.
Internationalised domain names are converted to their punycode form, default ports are recognised as defaults, and dot segments in paths are resolved, all exactly as a browser would do it.
Reading the components
- Origin: protocol, host and port together. This is what the same-origin policy compares, and why an API on a different port needs CORS headers.
- Path segments: the parts between slashes, listed separately. Useful when you are working out a routing pattern.
- Fragment: everything after the hash. Worth knowing that this is never sent to the server; it exists only in the browser.
- Credentials: a username and password embedded before the host. Long deprecated and a strong phishing signal, so the password is masked here.
Query parameters are where the information is
Each parameter is listed with its value already percent-decoded, which saves the step of copying values into a decoder one at a time. Repeated keys are shown as separate entries rather than collapsed, since ?tag=a&tag=b is a legitimate way to pass a list and a parser that keeps only the last value would mislead you.
Empty values are marked explicitly, because ?debug= and a missing debug parameter mean different things to most servers.
A note on suspicious links
Parsing a URL is a sensible thing to do with a link you were not expecting. The host is the part that matters, phishing links commonly put a familiar name in the path or a subdomain while the actual host is something else entirely. Reading example.com.attacker.net as a hostname makes the deception obvious in a way that scanning a long URL does not.
This parser only reads the text; it never fetches anything, so inspecting a hostile URL here is safe. To decode individual values by hand, the URL decoder handles that, and the URL encoder builds encoded values in the other direction.
Query strings are a convention, not a standard
The format of a query string is far less specified than people assume. Separating pairs with an ampersand and joining keys to values with an equals sign is convention, and semicolons were once an accepted alternative. How repeated keys behave, whether an empty value differs from an absent one, and how arrays are represented all vary between frameworks.
PHP expects tags[]=a&tags[]=b. Rails uses the same bracket notation. Many APIs expect a repeated plain key, and others want a comma-separated list in a single value. None of these is more correct than the others, which is why a parameter that works against one API fails against another. Reading the parameters as the server will is the only way to be sure, and checking the API's own documentation beats assuming.