Anatomy of a URL: What a Parser Sees

A URL looks like one string but is really a small sentence with labeled parts: who, where, what, and which fragment of the answer you want. A parser reads that sentence the way a browser does — and seeing the labels is the fastest way to stop being surprised by URLs.

The parts, labeled

Take a real address: https://shop.example.com:8443/catalog/shoes?color=blue&size=42&tag=sale%20items#reviews. Parsing it separates the scheme https:, the host shop.example.com, the port 8443, the path /catalog/shoes, the query ?color=blue&size=42&tag=sale%20items, and the fragment #reviews. It also derives the origin — https://shop.example.com:8443 — the scheme-plus-host value that CORS policies and cache keys are actually built from. Each part answers a different question, and most URL work is about one part at a time; the path portion gets its own treatment in How URL Slugs Work.

Query parameters, one by one

The raw search string is not quite what you want — it is what you want, encoded and glued together. The parser splits it on &, splits each piece at the first =, and decodes each value individually: color=blue, size=42, and tag=sale%20items comes back as the plain text "sale items". Notice what survived: the & and = stayed structural while the %20 inside a value became a space. That division of labor — encoding protects values, parsing recovers them — is the whole design, and the encoding half is detailed in URL Encoding: When %20 Matters.

Missing pieces get polite defaults

Paste shop.example.com/catalog — no scheme, no port, no query — and the parser assumes https://, exactly as browsers do. An absent port reports null rather than an invented default, the path never comes back empty (bare / at minimum), and a missing query or fragment is reported as null with a companion flag — hasQuery, hasFragment — that distinguishes "no parameters at all" from "a parameter with an empty value". Those are different facts, and code that treats them the same ships subtle bugs.

Parser or encoder?

The direction decides. The encoder rewrites text so it can safely occupy one slot of a URL; the parser reads a complete URL and tells you what each slot holds. They answer different questions about the same grammar: encoding is what you do before building a link, parsing is what you do after receiving one. If you are debugging a broken query string, parse it first — half the time the bug is a value that was never encoded, which the parser makes visible the moment an unescaped & splits one value into two.

Syntax, not semantics

A parser reads structure and nothing else. It does not contact the site, follow redirects, or check that the address exists — a URL for a domain that will never resolve parses just as cleanly as one that works. It also will not judge a URL's search ranking or predict how a server will route the request; what comes back when you actually visit is the territory of HTTP Status Codes Explained. What you do get is the normalized form — the exact href a browser would use — which is often subtly different from what you pasted: added scheme, trimmed defaults, decoded pieces.

Try it yourself

Paste a long URL from your browser bar into the URL Parser and read it part by part — the query parameters arrive already decoded, one per line. Then encode a parameter value in the URL Encoder & Decoder, rebuild the URL, and parse it again to watch the value survive the round trip. A stack of links to dissect at once goes into the URL Decode Batch.