What Happens When You Type a URL in the Browser?

Typing a URL (Uniform Resource Locator) into your browser’s address bar and pressing Enter initiates a sophisticated sequence of operations involving browser internals, operating system services, network protocols, and server-side logic. This process, although fast and seamless to the user, involves multiple steps under the hood.

Below is a comprehensive and technical breakdown of what actually happens.

1. URL Parsing and Validation

Once you enter a URL such as https://www.example.com/page?query=123:

• The browser verifies that the URL is syntactically correct based on the URI scheme.
• It decomposes the URL into its components:
  • Scheme/Protocol: https
  • Host/Domain: www.example.com
  • Port: Implicit 443 (for HTTPS) unless explicitly specified
  • Path: /page
  • Query String: ?query=123
  • Fragment (optional): #section (not sent to the server)

2. Browser Cache Checks

Before making any network requests, the browser attempts to retrieve the resource using locally stored data:

• Browser Cache: Checks whether the requested URL is stored and still valid based on caching headers like Cache-Control, ETag, or Last-Modified.
• DNS Cache: If the domain’s IP address was recently resolved, it may be reused.
• OS Resolver Cache: The operating system may have previously resolved and stored the domain’s IP address.
• Preload/Prefetch Cache: Resources that have been preloaded by the browser in anticipation of use are also checked.

If a cache hit occurs and is deemed fresh, the page can be served instantly without a network call.

3. DNS Resolution

If the IP address of the domain is not cached, the browser initiates a DNS resolution process:

• The browser queries the operating system.
• If unresolved, the OS sends a query to the DNS resolver (usually provided by the ISP or a custom DNS like Google DNS 8.8.8.8 or Cloudflare 1.1.1.1).
• The resolver may:
  • Use its own cache.
  • Query Root DNS Servers to find the authoritative server for the Top-Level Domain (TLD), such as .com.
  • Then query TLD DNS Servers to locate the authoritative server for example.com.
  • Finally, get the IP address from the Authoritative DNS Server of example.com.

The resolved IP address (e.g., 93.184.216.34) is returned to the browser and cached locally for future use.

4. Firewall and Network Intermediaries

Before a TCP connection is established, the outgoing request may pass through:

• Local Firewalls: On your device or operating system.
• Proxy Servers: Corporate or public proxies that inspect or reroute traffic.
• NAT Routers: If you’re on a private network, a Network Address Translation device rewrites the IP headers.

These intermediaries may block, inspect, or reroute traffic.

5. TCP Connection Establishment (3-Way Handshake)

To establish communication between the browser (client) and server, a TCP connection is made using the following steps:

1. SYN: The client sends a SYN packet to initiate the connection.
2. SYN-ACK: The server responds with a SYN-ACK packet acknowledging the request.
3. ACK: The client sends an ACK back to complete the handshake.

At this point, a full-duplex channel is established.

6. TLS/SSL Handshake (If HTTPS)

If the URL uses https://, the following steps occur:

• Client Hello: The browser sends a TLS handshake request, including supported cipher suites, TLS version, and a random number.
• Server Hello: The server replies with its certificate, chosen cipher, and its own random number.
• Certificate Validation: The browser checks the server’s SSL/TLS certificate against trusted Certificate Authorities.
• Key Exchange: Depending on the algorithm (e.g., RSA, ECDHE), the client and server agree on a shared secret for encryption.
• Session Key Generation: A symmetric session key is established using the shared secret.

This handshake ensures encryption, authentication, and data integrity for the connection.

7. HTTP Request is Constructed and Sent

Once the secure channel is established, the browser sends an HTTP request. Example:

GET /page?query=123 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Connection: keep-alive

The request includes:

• Method (e.g., GET, POST)
• Path and query string
• Headers (e.g., User-Agent, Accept, Authorization)
• Cookies (if any)
• Payload (for POST, PUT, PATCH)

8. Server Receives and Processes the Request

The server (e.g., Nginx, Apache, Node.js, etc.) performs the following:

• Parses the request and determines the requested resource.
• Routes the request to the appropriate controller or logic layer.
• Validates headers, cookies, authentication tokens, and session data.
• Queries databases, fetches files, or executes application logic.
• Constructs an HTTP response.

The response may include:

• Status Line (e.g., HTTP/1.1 200 OK)
• Response Headers (Content-Type, Set-Cookie, Cache-Control, etc.)
• Response Body (HTML, JSON, images, etc.)

9. HTTP Response is Returned to the Browser

Example HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1523
Cache-Control: max-age=3600

<html>
  <head><title>Example</title></head>
  <body>...</body>
</html>

The response is transmitted over the secure TCP connection.

10. Browser Renders the Web Page

Once the browser receives the HTML content, it performs multiple operations:

• HTML Parsing: Constructs the DOM (Document Object Model) tree.
• CSS Parsing: Loads stylesheets and builds the CSSOM (CSS Object Model).
• JavaScript Execution: Scripts are executed, possibly altering the DOM.
• Render Tree Creation: Combines DOM and CSSOM into a visual tree.
• Layout Phase: Calculates positions and dimensions of each node.
• Painting: Converts elements into visual pixels.
• Compositing: Assembles painted layers and displays them on screen.

If external resources are required (images, CSS, JS, fonts, videos), the browser sends parallel requests and repeats parts of the above process for each.

11. Additional Optimizations (Modern Web Performance)

• Lazy Loading: Defers loading of images or elements until visible.
• GZIP/Brotli Compression: Reduces response size for faster load.
• HTTP/2 and HTTP/3: Improves latency through multiplexing and header compression.
• Caching Headers: Optimizes repeated loads using ETag, Cache-Control.
• Service Workers: Allow background caching and offline capabilities.
• DNS Prefetch, Preconnect, Preload: Instructs the browser to prepare connections or resources early.

12. User Sees the Rendered Page

Once the browser completes rendering, the user sees the final page and can begin interacting with it. JavaScript continues to run in the background, handling dynamic content, event listeners, and asynchronous calls (AJAX, Fetch API).

Summary Flow

1. URL is parsed and validated.
2. Browser checks caches for stored content or DNS records.
3. DNS resolution maps domain to IP address.
4. TCP connection is established with the server.
5. TLS/SSL handshake secures the connection (for HTTPS).
6. HTTP request is sent to the server.
7. Server processes the request and returns a response.
8. Browser receives and parses the response.
9. Page is rendered using DOM, CSSOM, and JS.
10. User interacts with the fully loaded page.