b2KIT

URL Parser / Decomposer

Break down any URL into its components: protocol, host, path, query parameters, hash, and port.

Tested tool guide Tested browser tools Checked August 16, 2026

What URL Parser / Decomposer does, with a checked example

Paste a URL and get every piece labeled: protocol, username and password if present, host, port, path, query string, and hash. The parser applies the WHATWG URL rules that browsers use, so this is not a naive string split: hosts are lowercased, default ports disappear, and disallowed characters such as spaces come back percent-encoded (%20). The usual surprise is that the result can differ from what you pasted, and that query values are reported raw - a + stays a + and %20 stays %20 unless you decode them yourself. The whole parse runs in your browser, so the URL never leaves your machine.

Worked example

A concrete input and expected output from the current implementation.

Input

https://user:[email protected]:8080/path/to/page?q=hello+world&lang=en#section-2

Expected output

Protocol:  https
Username:  user
Password:  pass
Host:      example.com
Port:      8080
Path:      /path/to/page
Query:     q=hello+world&lang=en
  q    =  hello+world
  lang =  en
Hash:      section-2

The structural markers are read left to right: userinfo closes at @, the port stays 8080 because it differs from https's default (443), the path begins at the first / after the host, ? opens the query, # opens the fragment, and the query splits into two key=value pairs. Plus signs are left alone because only form encoding turns + into a space.

How the result is produced

1

Where the split happens

Components are cut at structural markers: the first colon ends the scheme, // opens the authority section, @ closes the username and password pair, a second colon marks the port, the first / starts the path, ? starts the query, and # starts the fragment. A character's role depends on position - a colon appears in the scheme, in userinfo, and in the port.

2

Normalization

The URL standard defines a canonical form, and the parser applies it: hostnames are lowercased, non-ASCII hosts are encoded as punycode (münchen.de becomes xn--mnchen-3ya.de), ports equal to the scheme default are removed (80 for http, 443 for https), and spaces or non-ASCII characters in path, query, or fragment become percent-encoded UTF-8 (%20, %C3%A9). What you pasted and what the tool reports can therefore differ.

Good uses

  • Debug a failing request: when a link 404s, a redirect loops, or an API rejects a URL, see which component is malformed - wrong host, missing port, mangled query - instead of squinting at the raw string.
  • Harvest the query parameters a shared link carries (tracking codes, filter state, pagination) so you can rebuild the URL programmatically in a test, a script, or a scraper with exactly the pairs that matter.
  • Find what actually differs between two near-identical URLs - trailing slash, explicit default port, added hash - when a server, cache key, or CORS rule treats them differently.

Limits and checks

  • The output is the normalized form, not your input: https://example.com:443/ reports no port (443 is https's default), EXAMPLE.com becomes example.com, and a pasted space becomes %20. Differences from your paste are the standard at work, not a bug.
  • Query values come back raw, not decoded. + is not a space in URLs - that rule belongs to form encoding - and %20 stays %20 until you decode it yourself. If the tool offers a decoded view, read the values there before judging what a parameter actually means.
  • A bare ? or # still counts: https://example.com/page? has an empty query and /page# an empty fragment, so "no query" and "empty query" are different states. And the fragment never travels to the server - two URLs that differ only in hash fetch the same resource.

Common questions

Why does https://example.com:443/ show no port?

Because 443 is the default port for https. The URL standard removes a port that matches its scheme's default while parsing, and the same happens to :80 on http and :443 on wss. A port survives only when it differs from the default, which is why 8080 appears in the example output and 443 would not. Requests to the default port are identical to requests without one.

Why did my host come back as xn--mnchen-3ya.de?

Your host contains a non-ASCII letter, and the URL standard encodes internationalized domain names as punycode during parsing: each non-ASCII label is transformed and prefixed with xn--, so münchen.de becomes xn--mnchen-3ya.de. That encoded form is exactly what DNS sees; browsers display the decoded name only as a convenience. The encoding is defined in RFC 3492.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools