URL Parser
Break any URL into its scheme, host, port, path, query parameters and hash, parsed locally in your browser.
Loading URL Parser… If nothing happens, please enable JavaScript.
A URL (Uniform Resource Locator) looks like a single string, but it is actually a structured record made of several distinct components, each with its own meaning. A full URL such as https://user:pass@example.com:8443/path/page?q=hello&lang=en#section packs in a scheme, optional credentials, a host, an optional port, a path, a query string, and a fragment. Reading those parts by eye is easy to get wrong, especially when the query string is long, contains percent-encoded characters, or repeats the same key more than once. A parser splits the URL precisely according to the rules defined in the WHATWG URL Standard, the same rules every modern browser follows.
Frequently asked questions
Is the URL I paste sent to a server?
What are the parts of a URL?
Why does the port show as default for some URLs?
What is the difference between host and hostname?
How are repeated query parameters handled?
Does it decode percent-encoded characters in query values?
Why do I get an invalid URL error?
Can it parse non-web schemes like mailto or ftp?
About URL Parser
This tool uses the native URL and URLSearchParams APIs built into your browser, so the results match exactly how a browser, a fetch call, or a server framework would interpret the address. It shows the scheme and full protocol, any username and password embedded in the authority, the host and hostname, the port (or a note that the default for the scheme applies), the pathname, the computed origin, and the hash fragment. The query string is broken out into a clean table of key and value pairs, with each value individually copyable, which is far quicker than hunting through a wall of ampersands and equals signs.
Everything runs locally in your browser. The URL you paste is never uploaded, logged, or sent to any server, so it is safe to inspect links that contain access tokens, session identifiers, signed parameters, or other sensitive query values. Developers reach for a URL parser when debugging redirects, OAuth callback URLs, tracking-parameter soup from marketing campaigns, API endpoints with many query options, or deep links in mobile apps. If the input is not a valid absolute URL, the tool shows a clear error rather than guessing.
The URL standard nobody agreed on for decades
URLs were first formalised by Tim Berners-Lee in RFC 1738 back in 1994, but for years afterwards every browser, library, and language parsed them slightly differently. Edge cases such as backslashes, leading and trailing whitespace, oddly placed colons, and percent-encoding in the host caused real security bugs, because a parser on the server and a parser in the browser could disagree about which host a URL actually pointed to. Attackers exploited those disagreements to slip past URL allow-lists and trigger server-side request forgery.
To end the chaos, the WHATWG published the URL Standard, a living specification that defines parsing as a precise state machine rather than a loose grammar. Crucially, the spec was written to describe what browsers actually do, including their quirks, so that the algorithm is interoperable by construction. The URL and URLSearchParams classes exposed to JavaScript implement this exact algorithm, which is why this tool's output matches what your browser's address bar and fetch calls see.
One subtle detail the standard nails down is the difference between special schemes (http, https, ws, wss, ftp, file) and everything else. Special schemes get extra normalisation, such as lowercasing the host and resolving the default port, while non-special schemes are treated more literally. That distinction explains why an https URL and a custom myapp URL with the same text after the colon can be parsed into quite different component values.