What Happens When You Type a URL? Step-by-Step Explained

You type a website address, press Enter, and a page appears. That moment feels instant. Behind it is a chain of protocols that every web developer eventually has to debug.

This article walks through what happens when you type a URL — from parsing the address to drawing pixels on the screen. The goal is not trivia. The goal is a mental model you can use when a site is slow, a certificate fails, or a request never leaves the browser.

Why Developers Should Understand This Flow

Every layer in this chain answers a different question:

• URL parsing: What exactly did the user ask for?
• DNS: Where is the server?
• TCP or QUIC: Can we talk reliably?
• TLS: Can we talk privately and with a trusted server?
• HTTP: What resource do we want, and what did we get back?
• Rendering: How does that response become a page?

When something breaks, it almost always belongs to one of those layers. Knowing the order lets you stop guessing.

This same sequence appears in browsers, mobile apps, API clients, load balancers, CDNs, and monitoring tools. It is one of the most reused ideas in software engineering.

Simple Explanation

A URL is a human-friendly address. Computers on the internet do not route packets to names like example.com. They route packets to IP addresses.

So the browser must:

1. Read the URL and split it into parts.
2. Look up the host name and get an IP address.
3. Open a connection to that IP on the right port.
4. Encrypt the connection if the site uses HTTPS.
5. Send an HTTP request for the path you asked for.
6. Receive HTML, CSS, JavaScript, images, and other files.
7. Parse those files and paint the page.

Think of it as finding a building by name, walking to the door, proving you are talking to the right building, handing over a written request, and then assembling the package you receive.

The URL Itself

A typical URL looks like this:

https://www.example.com:443/shop/item?id=42#reviews

The browser splits it into components:

• Scheme: https — which protocol stack to use
• Host: www.example.com — which name to resolve
• Port: 443 — which door on the server (default 443 for HTTPS, 80 for HTTP)
• Path: /shop/item — which resource
• Query: id=42 — extra parameters
• Fragment: #reviews — a location inside the page; this part is not sent to the server

If you type text with no dots and no scheme, many browsers treat it as a search query. If you type a host without a scheme, modern browsers usually try HTTPS first. Sites on an HSTS list are upgraded from HTTP to HTTPS before any request is sent.

How It Works Internally

The high-level path looks like this:

You type a URL
    |
    v
Browser parses URL and checks cache / HSTS
    |
    v
DNS resolver finds an IP address
    |
    v
OS routes packets across the network
    |
    v
TCP handshake (or QUIC)
    |
    v
TLS handshake (for HTTPS)
    |
    v
HTTP request and response
    |
    v
Browser builds DOM, CSSOM, render tree
    |
    v
Page is painted on screen

1. Browser checks local knowledge first

Before the browser talks to the internet, it looks nearby:

• Is this URL already open in another tab?
• Is there a cached copy of the page that is still fresh?
• Is the host on the HSTS list, so HTTP must become HTTPS?
• Is the IP already in the browser DNS cache or the operating system cache?

A cache hit can skip later work. A cache miss starts the network path.

2. DNS resolution: name to IP

DNS is the internet’s lookup service. The browser asks a resolver: “What IP address belongs to this host?”

The resolver typically checks its own cache. If the answer is missing or expired, it walks a hierarchy:

1. Root name servers point to the TLD servers for .com, .org, and so on.
2. TLD servers point to the domain’s authoritative name servers.
3. Authoritative servers return the A record (IPv4) or AAAA record (IPv6).

The answer includes a TTL. Caches keep the IP for that lifetime. That is why a DNS change is not always visible immediately.

Many browsers now send DNS queries over HTTPS (DoH) or TLS (DoT). The lookup still finds an IP. The difference is that the query itself is encrypted, so a network observer cannot as easily see which host you asked for.

A host can resolve to several IPs. The browser may try IPv6 first, then IPv4, or try more than one address if the first connection fails. This is called happy eyeballs.

3. Finding a route and opening a connection

The operating system now has a destination IP. Routing tables and your local gateway decide the next hop. Packets travel across your LAN, your ISP, and transit networks until they reach the server or a nearby CDN edge.

Most classic HTTPS sites then open a TCP connection on port 443. TCP starts with a three-way handshake:

1. Client sends SYN: I want to start a connection.
2. Server replies SYN-ACK: I agree, here is my sequence.
3. Client sends ACK: we are connected.

TCP gives a reliable, ordered byte stream. Lost packets are retransmitted. That reliability costs at least one round trip before any HTTP data moves.

HTTP/3 uses QUIC instead of TCP. QUIC runs over UDP, combines connection setup with encryption, and recovers from packet loss without blocking the entire connection the way TCP often does. You still get a reliable stream. The handshake is simply shorter.

4. TLS: identity and encryption

If the scheme is https, the browser and server run a TLS handshake before the HTTP request.

At a high level TLS 1.3 does this:

• The client sends supported versions, cipher suites, and key-share material.
• The server picks parameters, sends its certificate, and completes key agreement.
• The client checks the certificate chain against trusted certificate authorities, the host name, and the expiry date.
• Both sides derive session keys. Later bytes on the connection are encrypted and integrity-protected.

If the certificate is expired, issued for another name, or signed by an unknown authority, the browser stops and shows a warning. That is not decoration. It is the browser refusing to send your request to a server it cannot identify.

TLS session resumption can skip some of this work on later visits to the same site.

5. HTTP request and response

Now the browser can speak HTTP. A first request for a page looks like this:

GET /shop/item?id=42 HTTP/1.1
Host: www.example.com
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=abc123
User-Agent: ...

Important details:

• The path and query go in the request line. The fragment does not.
• Host tells a shared server which site you want. Many sites share one IP.
• Cookies the browser already stored for that site are attached automatically, subject to Secure, HttpOnly, Path, Domain, and SameSite rules.
• HTTP/2 and HTTP/3 can send this request as binary frames and multiplex several requests on one connection.

The server — or a CDN, reverse proxy, or application in front of a database — produces a response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=60
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax

<!DOCTYPE html>...

Status codes tell the browser what happened. 200 means success. 301 or 302 means follow another URL. 304 means use the cached copy. 404 means the resource is missing. 500 means the server failed.

The first response is usually HTML. That HTML references CSS, JavaScript, images, fonts, and APIs. Each of those URLs repeats a shorter version of the same pipeline. Connections are reused when possible so the browser does not pay a full handshake for every file.

6. Rendering the page

The browser does not wait for every file before doing work. It streams HTML and starts building structures:

• DOM: the document tree from HTML
• CSSOM: the style tree from CSS
• Render tree: visible nodes with computed styles
• Layout: sizes and positions
• Paint and composite: pixels on the screen

A <script> without async or defer can block parsing. CSS can block rendering. Images and fonts can shift layout if their sizes are not reserved. This is why performance work often starts with the critical rendering path, not with “make the server faster” as the only answer.

JavaScript then attaches event handlers, fetches more data, and updates the DOM. Those later fetches are still HTTP requests over the same kinds of connections.

Real-World Examples

Opening a news site. DNS often hits a cache. The first connection goes to a CDN edge near you, not to an origin server in another country. HTML is short. Dozens of images, ads, and scripts follow.

Logging into an app. After the page loads, a form POST or an API call sends credentials over TLS. The response sets a session cookie or returns a token. The next request includes that cookie. Without cookies or another credential, HTTP would treat every request as anonymous.

A slow checkout page. DevTools timing tabs split the delay: DNS, connect, SSL, waiting (TTFB), download, rendering. A 2-second wait after TLS usually means the server or database is slow. A long “connect” time often means distance, packet loss, or a failing handshake.

A certificate warning on a staging host. The TLS layer failed name matching. HTTP never ran. Fixing application code will not help until the certificate matches the host.

A mobile app calling an API. There is no HTML render step, but DNS, TCP/QUIC, TLS, and HTTP are the same. Timeouts you see in logs usually sit in one of those four stages.

A Small Code Example

You can observe part of this pipeline from a terminal. This does not replace browser DevTools, but it makes DNS and HTTP visible.

# Resolve the host
nslookup example.com

# See the HTTP response headers (follows redirects, uses HTTPS)
curl -sI https://example.com

In JavaScript running in a page, you only see the HTTP layer and the result. The browser has already finished DNS, TCP, and TLS:

const response = await fetch('/shop/item?id=42');
console.log(response.status);
const html = await response.text();

fetch looks simple because the platform hid the earlier steps. Those steps still ran, and they still appear in the Network panel.

Common Misconceptions

“The URL is sent as one string to the internet.” No. The host is resolved separately. The path goes in the HTTP request. The fragment stays in the browser.

“HTTPS is just HTTP with a lock icon.” HTTPS is HTTP inside TLS. Encryption, certificate checks, and extra round trips are real work. They also change how intermediaries can cache or inspect traffic.

“DNS only runs once ever.” DNS answers expire. Clients, resolvers, and CDNs all cache with TTLs. A new IP can take time to spread.

“One connection is one file.” HTTP/1.1 often opened many connections. HTTP/2 and HTTP/3 multiplex many requests on one connection. Connection reuse is a major reason repeat page loads are faster.

“The server always builds the page from scratch.” Caches exist at the browser, CDN, reverse proxy, and application layers. A 200 from a CDN edge may never touch your origin process.

“Rendering starts only after every file arrives.” The browser pipelines work. You can see a first paint long before every image and third-party script finishes.

Best Practices and Key Takeaways

• Learn the order: parse → DNS → connect → TLS → HTTP → render. Map every incident to one step.
• Use the browser Network panel. Read the timing breakdown instead of only staring at total load time.
• Prefer HTTPS everywhere. Set HSTS when you are ready so clients upgrade automatically.
• Keep DNS TTLs intentional. Low TTLs help failover. High TTLs reduce lookup work.
• Put static assets on a CDN close to users. The TCP and TLS cost shrinks when the edge is nearby.
• Enable HTTP/2 or HTTP/3 on the server so the browser can reuse connections well.
• Do not block the first render with huge synchronous scripts. The network can be fast and the page can still feel slow.
• Remember that APIs use the same transport path as pages. Timeout and retry logic should respect handshake cost.

FAQ

What happens first when you type a URL?

The browser parses the URL into scheme, host, port, path, query, and fragment. Then it checks local caches and HSTS rules before it contacts the network.

Why does the browser need DNS?

Packets are delivered to IP addresses, not domain names. DNS translates the host in the URL into one or more IPs the operating system can route to.

What is the difference between HTTP and HTTPS in this process?

Both send HTTP messages. HTTPS adds a TLS handshake after the transport connection is ready (or as part of QUIC). TLS authenticates the server and encrypts the bytes.

Is the TCP handshake the same as the TLS handshake?

No. TCP (or QUIC) creates a transport path. TLS negotiates keys and verifies the certificate. They are adjacent steps with different jobs.

Why do some pages load slowly after the address bar already shows the URL?

The name is known immediately. Delay usually comes from DNS, a distant handshake, a slow server response, large downloads, or expensive rendering and JavaScript.

Does the #fragment get sent to the server?

No. The fragment is used by the browser after the page arrives, for scrolling or client-side routing. Servers do not receive it in the HTTP request.

What is QUIC and why does it matter?

QUIC is the transport under HTTP/3. It runs over UDP, builds encryption into setup, and handles loss per stream. It can reduce connection time compared with TCP plus TLS.

How can I see these steps for my own site?

Open DevTools, go to Network, reload, and inspect timing for a document request. You will see DNS, connect, SSL, waiting, and download as separate phases.

Related Articles

• How DNS Works: The Internet's Phone Book Explained
• How HTTP Works: Request-Response Cycle Explained
• How HTTPS Works: TLS Handshake and Encryption Explained
• How Browsers Render Web Pages: The Critical Rendering Path
• How Cookies and Sessions Work: Complete Beginner's Guide
• How Authentication Works: Sessions, Tokens, and JWT

Target keyword: what happens when you type a URL. Related: URL to page load, DNS TCP TLS HTTP, browser request lifecycle, how websites load.