Anatomy of a URL

Every time you click a link, you're issuing a set of instructions. A URL tells your browser exactly how to find something: which protocol to speak, which server to contact, which resource to request, and which part to display.

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 65535.

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

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: Which Part?

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. The server receives https://example.com/docs and has no idea you're looking at #installation. Fragments are a secret between you and your client.

This makes them perfect for:

• Linking to page sections (scrolling to headings)
• Single-page app routing (changing views without server requests)
• Storing client-side state

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.