Paste a URL. Get a clean breakdown of every part: protocol, host, port, path, query, fragment. Each segment shown both encoded and decoded.
A browser or server never treats a URL as one flat string — it runs it through a parser that splits it into components along a fixed set of structural delimiters: ://, :, /, ?, and #. Getting that decomposition right matters, because mis-isolating a component is what causes broken routing, mismatched relative paths, lost attribution, and security holes like open redirects. The parser above uses the browser’s native URL engine, so its breakdown matches exactly what your code would see.
After the scheme, the // marks the start of the authority — the section that identifies who and where. Within it, two special delimiters carve out sub-parts:
@ credential boundary. If an @ appears inside the authority (as in https://admin:secret@example.com), everything before it is legacy user information — a username:password pair. Embedding credentials this way is discouraged for security reasons, but the parser isolates it rather than hiding it, so you can see it’s there.: port transition. A colon after the host (and after any @) introduces the port — a decimal number split off from the hostname as its own value (example.com:8080). The host resolves to an address; the port picks the channel on it.Order matters here: the parser has to find the @ first, because a colon before it belongs to the credentials (the password separator), while a colon after it is the port. Getting that sequence wrong is a classic parsing bug.
An absolute URL is complete — it includes a scheme and everything needed to locate the resource on its own. A relative reference (like ../../assets/main.js) has no host and only makes sense against a context. To resolve one, the parser combines it with an absolute base URL, walking the ../ and ./ steps up and down the directory tree to produce a single absolute destination.
In JavaScript this is the second argument to the URL constructor: new URL('../assets/main.js', 'https://example.com/app/page.html') resolves to https://example.com/assets/main.js. Feeding a parser a relative string with no base is a common reason resolution fails.
Parsing isn’t just cosmetic. When an app makes decisions from a URL — where to redirect, which host to fetch — a component that’s been mis-parsed or spoofed can enable an open redirect or a server-side request to an unintended host. Isolating the real host from the rest of the string, and validating it against an allowlist, is what keeps those decisions safe; our URL validator covers the validation side.
See also: How to split a URL into parts in Python 3 — a step-by-step guide with runnable code.
See also: How to extract the hostname from a URL — a step-by-step guide with runnable code.
URL object follows, which differs from RFC 3986 in a few parsing details. url.spec.whatwg.orgHonest scope: RFC 3986 defines URI syntax and reference resolution, but browsers follow the WHATWG URL Standard, which handles some edge cases (like certain special schemes and trailing characters) differently. This parser reflects the browser’s behaviour. Parsing confirms structure — it doesn’t guarantee a URL is reachable or safe to fetch.
It breaks a complete URL into its parts: protocol (scheme), host, port, path, query, and fragment. Paste a URL above and each component is shown separately, both encoded and decoded, so you can see exactly how it’s structured.
Modern browsers provide the URL object: new URL(urlString) exposes .protocol, .hostname, .port, .pathname, .search, and .hash. This tool uses that same native parsing, so the breakdown matches what your code would see.
After the :// that follows the scheme, the host runs up to the next /, ?, or # (or a : introducing a port). The parser isolates it for you, along with the port if one is present.
Everything after the # is the fragment identifier — a client-side marker the browser uses to jump to a section; it’s never sent to the server. The parser separates it from the path and query so you can see it on its own.
The path is the hierarchical route to a resource (/products/shoes); the query, after the ?, passes dynamic parameters to it (?color=red). The parser shows each separately.
A port (like :8080) specifies which network channel on the host to connect to; the hostname resolves to the server’s address. When a URL includes an explicit port, the parser displays it as its own field.
It recognizes the legacy username:password@host form and separates it. Embedding credentials in a URL is discouraged for security reasons, but older links and some tooling still use it, so the parser surfaces it rather than hiding it.
Yes. Non-HTTP schemes such as mailto:, tel:, or a custom myapp:// handler are parsed by extracting the scheme and showing the remaining payload, so you can inspect deep links and non-web URLs too.
A relative reference like ../assets/main.js has no host of its own; resolving it means combining it with an absolute base URL to get the full address. The URL constructor does this when you pass a base as its second argument.
Yes — entirely in your browser. The URL you paste is never uploaded, so it’s safe for links containing sensitive parameters, and the tool works with no network connection.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.