The anatomy of a URL
Every component the parser extracts maps to one slot in a single, well-defined structure:
scheme://user:pass@host:port/path?query#fragment
└─┬──┘ └───┬───┘ └┬─┘ └┬─┘└─┬─┘ └─┬─┘ └───┬──┘
protocol userinfo host port path query fragment| Part | Example | Notes |
|---|---|---|
| scheme | https | Required to anchor parsing |
| userinfo | user:pass@ | Legal but dangerous (see below) |
| host | api.example.com | May hold deep subdomains |
| port | :8443 | Implicit when standard (443/80) |
| path | /v1/search | Hierarchical resource locator |
| query | ?q=latte&lang=fr | Key-value pairs, order preserved |
| fragment | #results | Client-side only — never sent to the server |
The fragment never reaches the server
A frequent source of confusion: everything after # is stripped by the browser before the request leaves. It’s a client-side navigation anchor — used for in-page jumps and SPA routing — and the server has no idea it existed. So if you’re trying to read a value server-side and it lives after the #, it will never arrive. Move it into the query string (? section) if the backend needs it. This parser deliberately isolates the fragment in its own block to make that boundary visible.
Credentials in URLs are a liability
The user:pass@host form is valid per RFC 3986, but treat any URL containing it as compromised the moment it’s written down. Those credentials land in browser history, server access logs, Referer headers, proxy logs, and analytics — all in plain text. Modern browsers strip userinfo from many contexts precisely because it leaks so readily. If the parser surfaces a username and password in a link, that’s a flag to rotate the credential and move it into a proper Authorization header instead.
Encoding layers and the homograph trap
Two encoding subtleties bite regularly:
- Double-encoding.
%2520is%20that was itself percent-encoded — a single decode pass yields%20, not a space. If a parameter looks half-decoded, it was encoded twice; run it through a URL Encoder/Decoder for each additional layer. - Punycode / IDN homographs. Internationalised domains are encoded to ASCII as
xn--…. Attackers exploit this with look-alike characters — a Cyrillic “а” rendering identically to Latin “a” — to build convincing phishing domains. When a host displays in non-ASCII script, check its Punycode form; a legitimate brand domain almost never needs exotic homoglyphs.