What Really Happens When You Type a URL and Press Enter?

You open your browser. You type: https://example.com Then you press Enter. Within a few seconds, a webpage appears on your screen. It feels like a single action. But behind that Enter key is an entire chain of systems involving DNS, networking, TCP, TLS, HTTP, servers, databases, caching, and browser rendering. So what actually happens between typing a URL and seeing a webpage? The Big Picture A simplified journey looks like this: You Type a URL ↓ Browser Parses URL ↓ DNS Resolves Domain ↓ Connection Established ↓ TLS Encryption ↓ HTTP Request ↓ Web Server ↓ HTTP Response ↓ Browser Receives Resources ↓ HTML → CSS → JavaScript ↓ Page Rendered Let's follow this journey step by step. 1. You Type a URL Suppose you enter: https://example.com/products A URL contains several important components: https://example.com/products │ │ │ Protocol Domain Path Protocol https Defines how communication should happen. Domain example.com Identifies the website. Path /products Identifies the requested resource or route. The browser parses this information before starting the network request. 2. The Browser Checks Its Cache Before making a network request, the browser may check whether it already has useful information cached. Caching can exist at several levels: Browser Cache ↓ Operating System ↓ DNS Cache ↓ Network / CDN Cache ↓ Server If something can be reused safely, the browser may avoid downloading it again. This is one of the reasons returning to a website can sometimes feel much faster. 3. DNS Finds the Server Your browser knows the domain: example.com But networks communicate using IP addresses. So the browser needs to discover the appropriate IP address. This is the job of DNS - Domain Name System. Conceptually: example.com ↓ DNS ↓ IP Address For example: example.com ↓ 93.xxx.xxx.xxx The actual address depends on the domain and DNS configuration. 4. DNS Is Like the Internet's Phone Book Think about calling someone. You know their name, but your phone needs their number. DNS performs a similar translation: Domain Name → IP Address Without DNS, users would have to remember IP addresses instead of convenient domain names. Instead of: https://example.com you would have to enter something like: https://93.xxx.xxx.xxx DNS makes the internet much easier to use. 5. DNS Doesn't Always Start From Scratch DNS results can be cached. A simplified lookup might look like: Browser Cache ↓ OS Cache ↓ DNS Resolver Cache ↓ Authoritative DNS Server If the required information is already cached and hasn't expired, the system may avoid performing the entire lookup again. DNS records have a TTL (Time To Live) that helps determine how long cached information can be retained. This is another example of how caching improves performance. 6. Your Browser Needs a Network Connection Now your browser knows where the server is. It needs to communicate with it. For HTTPS, the connection generally involves modern transport networking such as TCP or QUIC, depending on the HTTP version and connection setup. A simplified traditional HTTPS flow is: Browser ↓ TCP Connection ↓ TLS ↓ HTTP ↓ Server Modern HTTP/3 uses QUIC, which runs over UDP and incorporates transport and security mechanisms differently. The exact path depends on the protocol and browser/server capabilities. 7. TLS Secures the Connection Because you're using: https:// the browser needs to establish a secure connection. This involves TLS - Transport Layer Security. Conceptually: Browser │ │ TLS Handshake ▼ Server │ │ Secure Connection ▼ Encrypted HTTP Communication TLS helps provide: - Encryption - Authentication - Integrity This helps prevent attackers on the network from simply reading or modifying the protected traffic. 8. The Browser Sends an HTTP Request Now the browser can send the actual request. A simplified HTTP request might look like: GET /products HTTP/1.1 Host: example.com The browser is essentially saying: "Please give me the /products resource fromexample.com ." The request can also contain headers such as: User-Agent Accept Accept-Encoding Cookie Authorization These provide additional information to the server. 9. The Request Reaches the Server The request travels through the internet: Browser ↓ Router ↓ ISP ↓ Internet ↓ Load Balancer / CDN ↓ Web Server The server receiving the request may not be a single machine. Large websites usually operate distributed infrastructure. A simplified architecture might look like: Users ↓ Load Balancer ↓ ┌──────────┼──────────┐ ↓ ↓ ↓ Server A Server B Server C The load balancer distributes requests across available infrastructure. 10. The Server Processes the Request Now the backend needs to determine what response to return. For example: GET /products could be handled by an application server. The backend might: Receive Request ↓ Authenticate User ↓ Run Application Logic ↓ Query Database ↓ Prepare Response For a simple static website, the server may simply return a pre-generated HTML file. For a dynamic application, it may need to execute backend code and access databases or other services. 11. The Database May Be Involved Suppose you're opening: /products The server may need product information. Conceptually: Browser ↓ Backend ↓ Database ↓ Product Data ↓ Backend ↓ HTTP Response The database might contain: Product ID Product Name Price Description Image URL The backend uses this data to construct the response. 12. Caching Can Make This Faster The server doesn't necessarily need to query the database for every request. It can use caching. For example: Request ↓ Cache ├── HIT → Return Cached Data │ └── MISS ↓ Database ↓ Store in Cache ↓ Return Data This can significantly reduce database load and improve response times. Caching is one of the most important performance techniques in web architecture. 13. The Server Sends an HTTP Response After processing the request, the server sends a response. A simplified response might look like: HTTP/1.1 200 OK Content-Type: text/html followed by the HTML content. For example: My Website Hello World The browser now has the first major piece of information it needs to construct the page. 14. What Does HTTP Status Code Mean? The response contains a status code. Common examples include: 200 → Success 301 → Permanent Redirect 302 → Temporary Redirect 304 → Not Modified 400 → Bad Request 401 → Unauthorized 403 → Forbidden 404 → Not Found 500 → Server Error For example: GET /products ↓ HTTP 200 OK means the request was successfully processed. 15. HTML Is Only the Beginning You might think: "The browser received HTML, so the page is done." Not yet. The HTML can contain references to other resources: Now the browser needs to request these resources too. Conceptually: HTML ↓ ├── CSS ├── JavaScript ├── Images ├── Fonts └── Other Resources This can result in many additional network requests. 16. The Browser Builds the DOM The browser parses the HTML and creates a structure called the DOM - Document Object Model. For example: Hello Welcome! can conceptually become: Document ├── h1 │ └── "Hello" │ └── p └── "Welcome!" The DOM represents the structure of the webpage. 17. CSS Creates the Visual Style The browser also downloads and processes CSS. For example: h1 { font-size: 32px; } The browser needs to determine: - Colors - Fonts - Sizes - Positions - Spacing - Layout This information contributes to the visual representation of the page. 18. JavaScript Makes the Page Interactive Modern websites often rely heavily on JavaScript. JavaScript can: - Handle user interactions - Fetch additional data - Update the DOM - Validate forms - Communicate with APIs - Create animations - Manage application state For example: HTML ↓ JavaScript ↓ API Request ↓ Backend ↓ JSON Response ↓ Update UI This is why a webpage can continue making network requests even after the initial HTML has loaded. 19. The Browser Builds the Render Tree The browser combines information from HTML and CSS to determine what should actually be displayed. A simplified rendering process is: HTML ↓ DOM ↓ CSS ↓ CSSOM ↓ Render Tree ↓ Layout ↓ Paint ↓ Composite ↓ Screen Layout Determines where elements should appear. Paint Determines how pixels should be drawn. Composite Combines visual layers before displaying them. The exact browser pipeline is more complex, but this is a useful mental model. 20. Then You Finally See the Page After all of this: URL ↓ DNS ↓ Connection ↓ TLS ↓ HTTP Request ↓ Server ↓ HTTP Response ↓ HTML ↓ CSS ↓ JavaScript ↓ Rendering ↓ Screen You finally see: The webpage. And this entire process can happen extremely quickly. 21. What If the Website Uses a CDN? Large websites often use a Content Delivery Network (CDN). Instead of: User → Origin Server the architecture can look like: User ↓ Nearby CDN ↓ Origin Server Static resources such as: - Images - CSS - JavaScript - Fonts - Videos can often be cached at CDN locations. This reduces latency and decreases the load on the origin infrastructure. 22. What If You Visit the Website Again? The browser can reuse cached resources. For example: First Visit ↓ Download CSS Download JS Download Images Later: Second Visit ↓ Check Cache ↓ Reuse Existing Resources The server can also use HTTP caching mechanisms such as: Cache-Control ETag Last-Modified This allows browsers and intermediary caches to avoid downloading unchanged resources unnecessarily. 23. What If Something Goes Wrong? Many things can fail. For example: DNS Failure ↓ Cannot find server Or: TLS Failure ↓ Secure connection cannot be established Or: 404 ↓ Resource doesn't exist Or: 500 ↓ Server-side error Modern web systems therefore rely heavily on: - Redundancy - Load balancing - Caching - Monitoring - Retries - Timeouts - Failover - Fault tolerance The goal isn't to assume that failures won't happen. It's to design for failure. The Complete Journey Let's put everything together: You ↓ Type URL ↓ Browser Parses URL ↓ DNS Resolution ↓ TCP / QUIC Connection ↓ TLS Handshake ↓ HTTP Request ↓ CDN / Load Balancer ↓ Web Server ↓ Application Logic ↓ Database ↓ HTT