The Anatomy of a URL: Every Part Explained

· 2 min read

Every URL, from the simplest homepage to a 500-character ad-tech monster, follows one grammar defined in RFC 3986. Learn the grammar once and you can read any URL on sight. Here is the full anatomy, using this specimen:

https://blog.example.co.uk:8080/articles/espresso?sort=new&page=2#reviews

Scheme — https

The scheme (or protocol) tells the client how to connect. https is HTTP over TLS; you'll also meet http, ftp, mailto, file, and app-specific schemes like spotify:. Everything before the :// is the scheme, and it is the only part of a URL that is officially case-insensitive along with the host.

Host — blog.example.co.uk

The host says where the resource lives. It reads right to left, from general to specific:

  • .uk — the top-level domain (TLD)
  • co.uk — the public suffix: the part under which people register domains. Note that it's two labels here; treating co.uk like a TLD is why naive domain parsers break on British, Australian, and Japanese URLs.
  • example.co.uk — the registrable domain, the part you actually own
  • blog — a subdomain, which the owner can point anywhere

Port — 8080

The port picks the specific service on the host. It's usually invisible because each scheme has a default — 443 for https, 80 for http — and browsers hide the default. An explicit port almost always means a development server or an internal tool.

Path — /articles/espresso

The path identifies what resource you want, structured like a filesystem: segments separated by slashes, with the final segment — the slug — naming the page. Paths are case-sensitive: /Articles and /articles may be different pages, which is one reason lowercase-everything is the safe convention.

Query string — ?sort=new&page=2

Everything after ? is the query string: key–value pairs joined by &, each pair separated by =. The query string carries data to the server — sort orders, filters, search terms, pagination — without changing which resource is addressed.

Two things make query strings hairy in practice. First, values must be percent-encoded, so real-world query strings are often unreadable. Second, marketing and analytics tools append their own parameters (utm_source, fbclid, gclid), which is how a clean link grows a 300-character tail. Both problems are inspection problems — a URL parser turns the wall of & and % into a readable table.

Fragment — #reviews

The fragment (or hash, or anchor) points inside the page — to an element with a matching id. Its defining property: the fragment is never sent to the server. The browser requests /articles/espresso, receives the page, then scrolls to #reviews on its own. This is why fragments power client-side routing in single-page apps, and why nothing you put after # will ever appear in server logs.

Userinfo — the part you'll (almost) never see

The full grammar also allows credentials before the host: https://user:pass@example.com. Browsers have spent two decades neutering this feature because it was mainly used for phishing (https://paypal.com@evil.example/). If you see an @ in a URL's authority section, read what comes after it — that's the real destination.

Paste any URL into the parser to see this breakdown live, including the subdomain/domain/public-suffix split that most string-based parsers get wrong.