A URL is a plan

When you type an address into a browser, you are not simply naming a page. You are giving the browser a compact plan: how to communicate, where to go, and what to ask for.

The parts of a URL

Consider this address:

https://learn.staticvar.dev/courses/web?mode=quick#dns

Each part has a job:

The fragment is special: browsers normally use it locally. It is not sent to the server as part of the HTTP request.

From name to destination

Before a browser can connect, it must turn a human-friendly host into an IP address. That is the role of the Domain Name System, or DNS.

sequenceDiagram
    participant You as Browser
    participant DNS as DNS resolver
    participant Server as Web server
    You->>DNS: Where is learn.staticvar.dev?
    DNS-->>You: Use 203.0.113.42
    You->>Server: Connect to 203.0.113.42
    Server-->>You: Connection established

DNS is like a directory, not a delivery service. It tells your browser where to connect; it does not carry the web page back.

One useful mental model

Think of a URL as an envelope with delivery instructions:

1. The scheme chooses the kind of courier.
2. The host is resolved into a deliverable address.
3. The path and query describe what you want from the recipient.
4. The fragment is your own note about where to look after opening it.

This model is imperfect—as all models are—but it gives you the right questions when something goes wrong. Did the name resolve? Was a secure connection possible? Did the server recognize the path?

Check your understanding

For https://example.com:8443/docs/start?lang=en#install, identify the scheme, host, port, path, query, and fragment. Then ask yourself which pieces the remote server receives.