Anatomy of a URL

Every time you click a link, you're issuing instructions to three different systems at once.

A URL is a Russian nesting doll of addressing. The scheme tells your browser which language to speak. The host points to a machine in the global DNS namespace. The path requests something from whatever internal namespace that machine has invented for itself. Three addressing systems, bolted together with punctuation.

Let's decode what each part actually does.

A Complete URL

Here's a URL with every possible component:

https://user:pass@www.example.com:8080/path/to/resource?key=value&foo=bar#section

Each piece answers a question:

Scheme: How Do I Connect?

The scheme appears first, followed by ://. It determines the protocol your browser uses:

• https — Encrypted web traffic (TLS)
• http — Unencrypted web traffic
• ftp — File transfers
• mailto — Opens email client
• file — Local files on your machine
• ws/wss — WebSocket connections

The scheme also implies a default port. When you visit https://example.com, your browser connects to port 443 without you specifying it.

Host: Where Is the Server?

The host identifies which machine to contact. It can be:

• A domain name: www.example.com
• An IPv4 address: 192.168.1.1
• An IPv6 address: [2001:db8::1] (brackets required)

Domain names are case-insensitive—EXAMPLE.COM and example.com reach the same server. The DNS system translates these names into IP addresses your browser can actually connect to.

Port: Which Door?

Servers listen on numbered ports. If you don't specify one, defaults apply:

• HTTP → port 80
• HTTPS → port 443
• FTP → port 21

When a server runs on a non-standard port, you specify it after a colon: example.com:8080. Port numbers range from 0 to 65,535.

Path: What Do I Want?

The path identifies the specific resource on the server:

/blog/2024/url-anatomy
/api/v2/users/123
/images/logo.png

This is where addressing gets interesting. The host pointed you to a machine. Now you're inside that machine's namespace—and every server invents its own. One maps paths to files on disk. Another routes them to database queries. A third generates responses from pure code. The path syntax is universal; what it means is entirely local.

Unlike domain names, paths are case-sensitive on most servers. /About and /about are different resources. An empty path defaults to / (the root).

Query: With What Parameters?

The query string starts with ? and contains key-value pairs separated by &:

?search=urls&category=networking&sort=date

Servers use query parameters for:

• Search terms: ?q=url+anatomy
• Filtering: ?status=published&year=2024
• Pagination: ?page=2&limit=20
• Tracking: ?utm_source=newsletter

The order of parameters usually doesn't matter.

Fragment: A Note to Yourself

The fragment starts with # and points to a section within the page:

https://example.com/docs#installation

Here's something genuinely strange: the fragment never leaves your browser. When you request this URL, the server receives https://example.com/docs and has no idea you're looking at #installation. The fragment is a note you're passing to yourself.

This makes fragments perfect for:

• Linking to page sections (scrolling to headings)
• Single-page app routing (changing views without server requests)
• Storing client-side state that shouldn't hit the server

The fragment isn't really part of the address. It's an instruction about what to do after you arrive.

URL Encoding

URLs can only contain certain ASCII characters. Everything else gets percent-encoded—the character's byte value in hexadecimal, prefixed with %.

Common encodings:

So "URL encoding & special characters" becomes:

?q=URL%20encoding%20%26%20special%20characters

Reserved characters like : / ? # & = have special meaning in URLs. Use them literally only in their designated roles. When you need them as data, encode them.

Unreserved characters never need encoding: A-Z a-z 0-9 - _ . ~

Absolute vs. Relative URLs

Absolute URLs include everything needed to find a resource:

https://www.example.com/path/to/page

Relative URLs are interpreted against the current page:

Relative URLs make sites portable—you can move between domains without rewriting every link.

Credentials in URLs

The URL spec supports embedding credentials:

https://user:password@example.com

Don't do this. These credentials appear in browser history, server logs, and referrer headers. Modern browsers warn against it. Use proper authentication instead.

Security Implications

Everything except the fragment goes to the server and potentially gets logged:

• Browser history captures full URLs
• Server logs record paths and query strings
• Referrer headers can leak URLs to third parties

Never put sensitive data (tokens, passwords, personal information) in query parameters. Use POST bodies or proper authentication headers instead.

Sources