URL Parser
Max 64 KB · Parses automatically as you type · A missing protocol is assumed to be https://
No protocol was given — assumed https://.
This URL contains credentials — avoid sharing it.
| Protocol | ||
|---|---|---|
| Username | ||
| Password | ||
| Hostname | ||
| Port | ||
| Host | ||
| Origin | ||
| Pathname | ||
| Search | ||
| Hash |
| Key | Value | Copy |
|---|
Processed entirely in your browser — nothing is sent to a server.
A URL looks like one string, but it’s built from several distinct parts, each with its own job — RFC 3986 calls this out explicitly: scheme://userinfo@host:port/path?query#fragment. The scheme (https) says which protocol to use. userinfo (user:pass@) is a legacy way to embed credentials directly in the URL — rare today, but still valid syntax, and still something to watch for since it’s easy to overlook. host and port say which server to connect to. path identifies a specific resource on that server. query (everything after ?) passes key-value parameters to it. fragment (everything after #) is a client-side-only reference — a scroll target, a client-router route — that’s never even sent to the server. This tool breaks a pasted URL down into exactly these pieces.
Why use a parser instead of splitting the string by hand (on ?, then &, then =)? Because a naive split gets real edge cases wrong: an IPv6 host’s own colons ([::1]) look exactly like a port separator to anything that isn’t syntax-aware, and a query value can use either percent-encoding or a literal + for a space. This tool is built entirely on the native URL API every browser already implements and tests against the same specification — not a hand-rolled parser — so it handles the same edge cases a browser’s own address bar does.
Two pitfalls worth watching for. Double-encoding — percent-encoding a value that’s already encoded turns % into %25, silently corrupting it — is why this tool always shows a query value’s decoded form next to its raw one: a double-encoded value shows up as a stray %25 where a plain % was expected. Fragment loss — a URL’s fragment is never sent to a server, resolved entirely client-side — is why the two are always shown as separate rows, never merged; if a value you expected a server to receive never arrived, checking whether it landed in the query string or the fragment is often the answer.
A missing protocol is assumed to be https://, and the result says so explicitly rather than guessing silently — this matters for one specific trap: text like localhost:3000 reads as a host and a port to a human, but to a bare URL parser the part before the first colon looks exactly like a scheme, leaving no host at all. This tool detects that shape and falls back to https:// instead of reporting a technically-parsed but useless result.
Examples
- Debugging a complex API request URL — paste one with query parameters and a fragment together, e.g. a paginated search URL, and see the path, every query parameter, and the fragment broken out individually instead of squinting at one long string. If you need to build or re-encode a value like this by hand afterward, <a href="/tools/url-encode-decode">URL Encode/Decode</a> is the direct next step.
- Auditing a URL before sharing it — paste one containing userinfo (<code>https://user:pass@host/...</code>), a legacy but still-valid way to embed credentials directly in a URL, and get an explicit, non-color-only warning that it contains credentials before you paste it somewhere public.
- Reading a redirect or referrer chain — paste the value of a <code>Location</code> or <code>Referer</code> response header (captured with <a href="/tools/http-header-parser">HTTP Header Parser</a>) to see exactly which host, path, and query parameters it points to, rather than reading the raw string by eye.
Frequently asked questions
Is my URL sent anywhere?
URL API every browser already implements — no library, no network request. This matters more here than for most tools on this site: a real URL routinely carries an API key in a query parameter, a session token in a fragment, or literal credentials in its userinfo, and none of it ever leaves your device.What happens if I paste a URL without https:// at the start?
https:// first, and the result says so explicitly above the breakdown — this tool never silently guesses. This matters for a specific, easy-to-miss trap: something like localhost:3000 or example.com:8080 looks like a host and a port to a human, but a bare URL parser reads the text before the first colon as the scheme instead, leaving no host at all. This tool detects that shape specifically and falls back to assuming https://, rather than reporting a technically-valid but useless result.What happens with duplicate query parameters, like ?tag=a&tag=b?
Does this support IPv6 hosts?
[::1] or [2001:db8::1] is recognized correctly as the host, brackets included (they're part of the URL syntax that disambiguates an IPv6 address's own colons from the URL's host:port separator).Why do I see both a decoded and a raw form for some query values?
%20 for a space, %C3%A3 for "ã") or a + standing in for a space — the table always shows the decoded, human-readable form, and adds the original raw form underneath only when it's actually different from the decoded one, so a plain unencoded value (most of them) isn't cluttered with a redundant second line.