What Really Happens When You Press Enter After Typing a URL?

Every day, we type domain names into our browsers and press Enter without a second thought. Pages load in milliseconds, but behind that simple, near-instant action lies an incredibly complex, highly synchronized orchestra of networking protocols, physical hardware routing, cryptographic mathematics, and client-side rendering engines.

In this post, we will follow the step-by-step path of a single request—specifically typing https://vsidhu.com/blogs—from your keypress to the final pixel paint on your screen.

1. URL Parsing: Breaking Down the Request

The moment you type the address and hit Enter, the browser's first task is to parse the string. A URL (Uniform Resource Locator) has a strict structure. Consider this complete example:

The browser breaks it down into its constituent parts:

• Protocol (Scheme): https. Tells the browser to use HTTP over TLS (secure).
• Host (Domain Name): vsidhu.com. The human-readable name of the server.
• Port: 443. The communication channel. If omitted, the browser infers the protocol's default: Port 80 for HTTP, Port 443 for HTTPS.
• Path: /blogs. The specific resource page we want to view.
• Query Parameters: ?id=10. Dynamic variables passed to the server-side code.
• Fragment: #comments. An anchor tag referencing a specific location on the page. The browser scrolls here directly; this fragment is never sent to the server.

2. The Browser Cache Check

Before hitting the network card, the browser tries to avoid the internet entirely. It asks: "Have I already downloaded this resource recently?"

The browser checks several caching layers:

• Memory Cache: Fast, temporary storage in RAM. Files are held here only during the active browser session.
• Disk Cache: Persistent storage on your SSD/HDD. The browser reads HTTP headers (like Cache-Control or ETag) to determine if a cached file on disk is still fresh.
• DNS Cache: Checks if it already knows the IP address for the domain, saving a slow DNS query round-trip.

If the asset is cached and still valid, the browser loads it instantly, bypassing all network steps.

3. DNS Resolution: Translating Domain Names to IP Addresses

If there is a cache miss, the browser must find the server's physical location. Computers communicate using IP addresses (like 142.250.190.46), but humans use domain names (like vsidhu.com). Translating the domain name is the job of the Domain Name System (DNS).

The DNS lookup processes through a hierarchy of caches and servers until it finds the IP:

Browser DNS Cache ──(Miss)──> OS Hosts File / Cache ──(Miss)──> Router DNS Cache
                                                                     │
                                                                   (Miss)
                                                                     │
                                                                     ▼
Authoritative Server <──(IP)── TLD Server (.com) <──(IP)── ISP Recursive Resolver
      

Recursive Resolver vs. Authoritative Resolver

• Recursive Resolver: Typically operated by your ISP or a public provider (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8). It acts as your agent, doing the legwork of querying other servers sequentially on your behalf.
• Authoritative Resolver: The final authority in the chain. It actually holds the master DNS configuration record for the target domain and returns the matching IP address.

If the ISP recursive resolver doesn't have the IP cached, it queries the Root DNS Server, which redirects it to the TLD (Top-Level Domain) Server responsible for .com. The TLD server points the resolver to the domain's Authoritative DNS Server, which returns the IP address. The resolver returns it to the OS, which returns it to the browser, caching it at every stage along the way.

4. ARP: Finding the Local MAC Address

Once the browser knows the server's IP address (e.g. 185.199.108.153), it prepares to send data. However, the hardware layers (Ethernet or Wi-Fi) don't understand IP addresses. They use physical MAC (Media Access Control) Addresses.

Before your computer can send a packet to your home router, it must discover the router's MAC address using the Address Resolution Protocol (ARP):

1. Your computer checks its local ARP cache.
2. If there is a miss, it broadcasts an ARP Request packet to the entire local network: "Who owns IP 192.168.1.1? Tell me your MAC address."
3. The gateway router recognizes its IP and replies with an ARP Reply containing its hardware MAC address.
4. Your computer stores the MAC address in its ARP cache and uses it to frame the outgoing network frames.

5. The TCP Handshake: Establishing the Connection

With the IP and MAC addresses in hand, the browser initiates a transport connection. Since HTTP requires reliable transmission (you don't want your webpage code to arrive out of order or missing lines), it uses the Transmission Control Protocol (TCP). To open a connection, the client and server execute the famous 3-Way Handshake:

Client                                   Server
  │                                        │
  │ ─── SYN (Synchronize Sequence No.) ──> │
  │                                        │
  │ <── SYN-ACK (Acknowledged + Sync) ──── │
  │                                        │
  │ ─── ACK (Acknowledge) ───────────────> │
  ▼                                        ▼
Connection Established
      

Why do we need this?

• Sequence Numbers: Both sides agree on initial sequence numbers so they can reconstruct out-of-order packets and detect lost segments.
• Reliability: It guarantees that both client and server are physically online and capable of bidirectional communication before sending heavy payload data.

6. The TLS Handshake: Securing the Connection

Because our URL uses https, we must encrypt the connection using Transport Layer Security (TLS). The TLS handshake establishes shared cryptographic keys to encrypt all subsequent HTTP data:

• Client Hello: The browser sends its supported TLS version, compression algorithms, and a list of compatible Cipher Suites (cryptographic algorithms).
• Server Hello: The server selects the TLS version and Cipher Suite it wishes to use. It also sends its SSL Certificate.
• Verification: The browser verifies the certificate against built-in Root Certificate Authorities (CAs). If verified, the browser is confident it is talking to vsidhu.com and not an impostor.
• Key Exchange: The client and server exchange random data using asymmetric encryption (public/private keys) to compute a shared, secret Session Key.
• Encrypted Session: Both sides transition to symmetric encryption using the session key (which is much faster than asymmetric encryption for large transfers).

7. The HTTP Request

Now that the secure channel is open, the browser finally sends the actual payload: an HTTP request. It formats a raw text string and writes it to the socket:

GET /blogs HTTP/1.1
Host: vsidhu.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) Chrome/120.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Encoding: gzip, deflate, br
Cookie: session_id=abc123xyz
Authorization: Bearer my-token

Let's dissect these headers:

• GET /blogs: The HTTP method (read resource) and the path location.
• Host: Crucial for servers hosting multiple domains on a single IP address (virtual hosts).
• User-Agent: Describes the client's browser and operating system details.
• Accept-Encoding: Informs the server that the browser can unpack compressed payload types (like gzip, deflate, or Brotli).
• Cookie: Automatically includes cookies matching the domain to maintain session state.

8. Packetization: Splitting Data for Transit

If the server wants to return a 3 MB image, it cannot send it as a single chunk. Networks enforce limits on size. The browser and network stacks split data into individual Packets:

• MTU (Maximum Transmission Unit): The maximum size of a packet at the physical network layer, typically 1500 bytes for standard Ethernet.
• MSS (Maximum Segment Size): The maximum TCP payload size (usually MTU minus IP/TCP header sizes, leaving about 1460 bytes for data).
• Fragmentation: If a packet encounters a network link with a smaller MTU along its journey, intermediate routers will split it into smaller packets and rebuild them at the destination.

9. TCP vs. UDP: Transport Philosophies

Web protocols rely on two distinct transport layer protocols depending on whether they value correctness or speed:

10. The Physical Journey Across the Internet

Once your network card converts the digital packet into electrical signals (Ethernet) or radio frequencies (Wi-Fi), the packet embarks on a physical journey across the globe:

Your Device ──> Home Router ──> ISP Central Office ──> Fiber Backbone Cable
                                                           │
                                                           ▼
Server <── Load Balancer <── Reverse Proxy (Nginx) <── Edge Network (Cloudflare)
      

Each intermediate device along this path acts as a router. The packet does not carry a pre-computed map of how to reach the server. Instead, each router inspects the destination IP address and checks its internal Routing Table to decide the next best Hop (next router interface). The packet's TTL (Time-To-Live) counter is decremented by 1 at each hop. If TTL reaches 0 before arrival, the packet is discarded, preventing infinite loop routing loops.

11. Server Receives & Processes the Request

When the packets arrive at the server's data center, they pass through a series of software and hardware gates:

1. Load Balancer: Distributes incoming traffic across multiple physical web servers.
2. Reverse Proxy (e.g., Nginx): Receives the connection, handles SSL decryption, terminates the TLS session, and forwards the raw HTTP call to the internal application port.
3. Application Middleware: In an Express or NextJS backend, middleware intercepts the call to run token authentication, rate limit checks, and parser transformations.
4. Controller: Executes business logic, runs SQL database queries, and formats an HTML page.
5. Response Dispatch: The server sends back an HTTP response containing headers (like Content-Type: text/html) and the raw HTML text string, splitting it back into packets to travel back to the browser.

12. Browser Rendering Engine: Drawing the Screen

Once the browser receives the raw HTML bytes, its layout and painting thread springs to life to render the layout on screen:

HTML Bytes ──> DOM Tree ──┐
                          ├──> Render Tree ──> Layout ──> Paint ──> Composite
CSS Bytes ──> CSSOM Tree ─┘
      

• DOM (Document Object Model): The browser parses HTML tags into a tree node structure.
• CSSOM (CSS Object Model): The browser parses stylesheet rules into selectors and values.
• Render Tree: Combines the DOM and CSSOM, keeping only elements that are visible on screen (e.g., elements marked display: none are excluded).
• Layout (Reflow): Computes the exact dimensions and coordinate locations of each box element on the page.
• Paint: Fills in colors, borders, images, and text shadows, drawing visual details into layers.
• Composite: Sends the finished layers to the GPU to merge them and draw the final canvas onto your screen.

13. JavaScript Execution

During HTML parsing, if the browser encounters a script tag: <script src="app.js"></script> it halts HTML parsing to download and run the script, which is known as Parser Blocking.

To optimize load performance, developers use script attributes:

• async: Downloads the script in the background and runs it the millisecond download completes, interrupting HTML parsing.
• defer: Downloads in the background and waits to execute until the HTML parser has completely finished constructing the DOM.

14. Additional Network Requests

An HTML document is rarely self-contained. As the browser parses the nodes, it discovers link and image tags pointing to external assets: stylesheets, Javascript files, web fonts, images, videos, and dynamic API fetch requests.

For every one of these assets, the browser initiates the entire lifecycle again—resolving DNS, opening TCP connections (or reusing existing ones), and negotiating caching rules.

15. Modern Protocol Advancements: HTTP/2 & HTTP/3

Because requesting dozens of assets sequentially creates massive bottlenecks, web standards have evolved:

• HTTP/1.1: Opens separate TCP connections for each request. Limited by browser rules to about 6 parallel connections per domain, causing "Head-of-Line Blocking".
• HTTP/2: Introduces Multiplexing over a single TCP connection. Multiple requests and responses interleave concurrently, reducing connection overhead.
• HTTP/3: Replaces TCP entirely with QUIC (running over UDP). It eliminates TCP handshake delays and packet loss bottlenecks where a single lost packet blocks all streams.

16. Common Web Performance & Reliability Questions

• Why is DNS cached?
  Querying root and authoritative DNS servers takes 50-150ms. Caching it locally reduces the latency to 0ms for subsequent requests.
• Why does the first request to a page take longer?
  The initial load requires full DNS lookup, ARP discovery, TCP 3-way handshake, TLS negotiation, and cold server-side database caches. Subsequent requests reuse established connections and pull resources from cache.
• What happens if one packet is lost in transit?
  Under TCP, the receiver notices a missing sequence number and requests retransmission. Under HTTP/1 and HTTP/2, this halts all communication (Head-of-Line blocking). Under HTTP/3 (QUIC), only the affected stream is blocked, while other data streams continue executing.

The Complete Timeline

Putting it all together, here is the complete sequence of events from keypress to screen draw:

[User types URL & hits Enter]
         │
         ▼
[1] URL Parsing (Protocol, Host, Port)
         │
         ▼
[2] Browser Cache Check (Memory, Disk, DNS)
         │
         ▼
[3] DNS Resolution (Recursive -> Authoritative)
         │
         ▼
[4] ARP Request (Find local router MAC)
         │
         ▼
[5] TCP 3-Way Handshake (SYN -> SYN-ACK -> ACK)
         │
         ▼
[6] TLS Handshake (Cipher Suite exchange & Certificate verification)
         │
         ▼
[7] HTTP GET Request Sent
         │
         ▼
[8] Packetization (MSS splits into 1500-byte packets)
         │
         ▼
[9] Routing (Hops across internet backbone)
         │
         ▼
[10] Server Processing (Nginx -> Express middleware -> DB query)
         │
         ▼
[11] Response Travel (Packets stream back)
         │
         ▼
[12] DOM + CSSOM construction
         │
         ▼
[13] Layout (Dimension calculation)
         │
         ▼
[14] Paint & Composite (GPU draws layers)
         │
         ▼
[Page Is Visually Rendered & Interactive]
      

Thanks for reading.