URL Parser
How to use this URL parser
- Paste any full URL into the field above.
- It instantly breaks down into protocol, hostname, port, path, query parameters, and hash.
- Useful for debugging redirects, webhooks, or understanding a complex link.
What are the parts of a URL?
A URL is structured as protocol://username:password@hostname:port/pathname?query#hash. Each part serves a specific purpose — the protocol defines how to connect, the hostname identifies the server, and the query string carries parameters to the application.
What is the "origin" of a URL?
The origin combines protocol, hostname and port (e.g. https://example.com:8080). Browsers use it to enforce security boundaries like the Same-Origin Policy.
Why is the port sometimes empty?
If a URL doesn't specify a port, the browser uses the protocol's default (80 for HTTP, 443 for HTTPS), so this tool shows "(default)" instead of a number.
Why "origin" is the unit browsers actually use for security
Of everything a URL contains, the origin — the combination of protocol, hostname, and port — is the specific piece browsers use to enforce the Same-Origin Policy, one of the web platform's most fundamental security boundaries. Two URLs share an origin only if all three of those pieces match exactly: https://example.com and http://example.com are different origins purely because of the protocol, and https://example.com and https://example.com:8080 are different origins purely because of the port, even though both point to what a person would casually call "the same site." This matters immensely in practice — it's the mechanism that prevents a malicious script loaded from one origin from reading cookies, local storage, or DOM content belonging to a page from a different origin, which is why understanding exactly what does and doesn't count as "the same origin" is genuinely important for web security, not just a technical curiosity.
Why the username:password@ URL syntax is now considered dangerous
The URL spec technically allows embedding credentials directly in a URL using the format protocol://username:password@hostname, and while this was more common in the past, modern browsers actively discourage and, in various contexts, actively block it — for good reason. Credentials embedded this way end up stored in plain text in browser history, server logs, the Referer header sent to other sites, and anywhere else the URL happens to get copied or logged, none of which are places you'd want a password sitting in plain text. Because of these risks, modern browsers like Chrome strip or refuse to display this userinfo component in the address bar, and some outright block navigation to URLs using it for certain protocols, specifically to make this pattern harder for phishing sites to abuse by disguising a malicious hostname as if it were a "username" in front of a legitimate-looking one.
Why query strings can't always be parsed as simple key-value pairs
A query string looks like a simple list of key=value pairs joined by "&", but there's no single official standard dictating exactly how repeated or complex parameter names should be interpreted — different frameworks and languages have each developed their own, sometimes incompatible conventions. A URL containing "?tags=a&tags=a&tags=b" might be interpreted as an array of tags by one backend framework, while another simply keeps only the last "tags" value and discards the earlier ones. Some frameworks additionally support bracket notation like "filter[status]=active" to represent nested or structured data within a flat query string. This means the "correct" interpretation of a query string with repeated or complex keys genuinely depends on the specific backend framework or library receiving it, not on some universal rule everyone follows the same way.
Why the hash fragment never reaches the server at all
The portion of a URL after the "#" — the fragment or hash — behaves fundamentally differently from every other part of a URL: browsers deliberately never send it to the server as part of the HTTP request. It exists purely for the browser's own use, originally designed for jumping to a specific anchor within a page, but modern single-page JavaScript applications widely repurpose it for entire client-side routing systems specifically because changing it doesn't trigger a full page reload or a new server request the way changing the path does. This is exactly why a URL's hash can safely carry sensitive session state in some client-side authentication flows (like older OAuth implicit-grant flows) — because unlike query parameters, it's structurally guaranteed to never appear in server access logs.
Limitations of this tool
This tool parses a URL into its standard components using your browser's built-in URL parsing, correctly handling the general structure described above — but it doesn't attempt to interpret query parameters using any particular framework's array or nested-object conventions (like bracket notation), since as explained above there's no single universal standard for that. It also doesn't validate that a URL's hostname actually resolves to a real server or that the URL is reachable — it only parses the text structure of the URL you provide, entirely offline in your browser.