URL Parser

This tool parses a URL into its component parts in your browser; nothing leaves your machine. The interesting part of URL parsing is knowing what each component does and where the boundaries are.

The full URL grammar

scheme://userinfo@host:port/path?query#fragment
  │       │      │     │   │     │       │
  │       │      │     │   │     │       └─ fragment (client-only; not sent to server)
  │       │      │     │   │     └─ query string (key=value&key=value)
  │       │      │     │   └─ path (the resource location)
  │       │      │     └─ port (defaults from scheme)
  │       │      └─ host (domain or IP)
  │       └─ user[:password] (deprecated for browsers)
  └─ scheme (http, https, ftp, mailto, etc.)

Most URLs use only some of these. A typical web URL:

https://www.example.com:443/path/to/page?id=42&debug=true#section-2

Mailto and other schemes use different structures:

mailto:user@example.com?subject=Hello
ftp://user:pass@ftp.example.com/file.txt
file:///C:/Users/Alice/document.pdf

The tool above parses all of these with the browser’s URL parser and lists each component — including the username and password when a URL carries them.

What each part is for

Scheme

The protocol. Determines how the rest is interpreted.

Userinfo

user[:password] before @. Deprecated in browsers — modern browsers ignore credentials in URLs and may show a warning. Used historically for HTTP Basic auth.

Host

The domain name or IP address. Examples:

• example.com
• subdomain.example.com
• 192.168.1.1
• [::1] (IPv6 in square brackets)
• localhost

The host is case-insensitive. Example.com and example.com are the same.

Port

The TCP port, after :. Defaults derive from scheme:

• http:// → 80
• https:// → 443
• ftp:// → 21
• ws:// → 80
• wss:// → 443

https://example.com/ and https://example.com:443/ are equivalent.

Path

The resource path, like a filesystem path. Case-sensitive on Unix-derived servers (Linux), case-insensitive on Windows IIS. Always starts with /.

/                            ← root
/path/to/page
/path/with-hyphens-and_underscores
/path/with%20encoded%20spaces

Path components separated by /. The query string starts at ?; any / before that is path.

Query

After ?. Conventionally key=value pairs joined by &:

?id=42&name=Alice&debug=true

Multiple values for the same key are allowed:

?tag=red&tag=blue&tag=green

Different frameworks parse this differently — some give you tag = "green" (last wins), some give you tag = ["red", "blue", "green"] (array). Check your parser.

Fragment

After #. Not sent to the server — fragments are client-side only. Used for:

• Anchor links to a section of a page (#section-2).
• Single-page-app routing (#/dashboard/users).
• Auth tokens in implicit flow (the fragment doesn’t appear in server logs, which is the security property).

URL encoding

Most URL components allow only specific characters. Anything else gets percent-encoded. See URL encode for the rules.

Original:  search?q=hello world
Encoded:   search?q=hello%20world

Original:  path/with spaces
Encoded:   path/with%20spaces

A correct URL parser percent-decodes when extracting components, so %20 in the parsed query becomes a literal space.

Common parsing tasks

• Extract the domain. Get the host component.
• Extract a query parameter. Parse the query string and get the value for a specific key.
• Modify a query parameter. Parse, change, re-serialize.
• Strip the fragment. For URLs being recorded server-side, the fragment is useless.
• Validate that a URL is well-formed. A URL parser returns errors on malformed input.

The tool above covers the read-only ones: the host, every query parameter (decoded), the fragment, and whether the URL parses at all. To modify a parameter and re-serialize, use URL and URLSearchParams in code.

What URL parsing doesn’t do

• It doesn’t validate that the URL is reachable. A perfectly-parsed https://does-not-exist-12345.example/ is structurally valid; whether anything answers is a network operation.
• It doesn’t follow redirects. That’s an HTTP client.
• It doesn’t normalize. http://example.com/path and http://example.com/path/? may be the same resource or different ones; the parser doesn’t decide.
• It doesn’t escape for security. A URL extracted from one context and inserted into another (HTML attribute, SQL string) needs context-specific escaping. See HTML encode, string escape.

Common pitfalls

• Treating the URL as a string. Manipulating URLs by string concatenation breaks subtly when components contain special characters. Use a URL library.
• Forgetting URL encoding. A query parameter with a & in its value, unencoded, looks like the boundary between two parameters.
• Case sensitivity confusion. Hostnames are case-insensitive; paths are case-sensitive (on most servers). EXAMPLE.com/Page and example.com/Page are the same; example.com/Page and example.com/page may not be.
• // without scheme. //example.com/ is a protocol-relative URL — uses the same scheme as the page that contains it. Browsers handle correctly; some parsers don’t.
• Userinfo in the URL. Modern browsers strip these or warn. Don’t put credentials in URLs; use proper authentication.
• Internationalized domain names (IDN). münchen.de is encoded as xn--mnchen-3ya.de in DNS (punycode). A URL parser may or may not normalize between forms.

For URL encoding/decoding, see URL encode and URL decode.