What happens when you type a URL in the browser and press Enter?
The browser finds the server's IP address with DNS, opens a TCP connection, sets up TLS for HTTPS, sends an HTTP request, gets a response and then parses and renders the HTML, CSS and JavaScript into the page you see.
Explain it simply
Typing a URL is like sending a letter to a shop you only know by name. First you look up the shop's address in a directory (DNS). Then you call ahead to check they are open (TCP handshake), agree on a secret language so nobody on the way can read your letter (TLS). You send your order (HTTP request), the shop sends back a parcel (HTTP response), and you unpack and arrange everything on your table (rendering).
Example
You type https://aitapri.com/tools and press Enter:
- URL parsing: the browser splits it into scheme
https, hostaitapri.comand path/tools. - Cache check: it looks for a cached page or a cached DNS answer first.
- DNS lookup: browser cache, then OS cache, then your router, then a resolver (like your ISP's or 8.8.8.8), which asks root,
.comand finally the domain's name server. The answer is an IP address such as76.76.21.21. - TCP connection: a three-way handshake, SYN, SYN-ACK and ACK, on port 443.
- TLS handshake: the server shows its certificate, the browser checks it and both sides agree on encryption keys.
- HTTP request:
GET /toolswith headers likeHost,User-Agentand cookies. - Server work: a load balancer or CDN passes the request to an app server, which may read a database and builds the response.
- Response: status
200 OK, headers and the HTML body. - Rendering: the browser builds the DOM from HTML and the CSSOM from CSS, runs JavaScript, calculates layout and paints pixels.
How it works
Each step sits on a different layer. DNS and HTTP are application-layer protocols. TCP gives reliable, ordered delivery at the transport layer. IP routes packets hop by hop across routers at the network layer. Modern sites often use HTTP/2 or HTTP/3; HTTP/3 runs on QUIC over UDP, which merges the transport and TLS handshakes to save time. While parsing HTML, the browser finds more resources (CSS, JS, images, fonts) and fetches them, often reusing the same connection.
Real-world use
This is why sites use CDNs (the server is physically closer), long cache lifetimes for static files, and preconnect hints. When a page is slow, developers open the Network tab in DevTools and look at exactly these phases: DNS, connect, TLS, waiting (server time) and download.
Common mistakes
- Forgetting DNS and jumping straight to "the browser sends a request".
- Saying HTTPS encrypts the domain name. The IP address is visible, and the domain is usually visible in the TLS handshake unless Encrypted Client Hello is used.
- Mixing up TCP handshake (connection) with TLS handshake (encryption).
- Stopping at "server sends HTML" and skipping rendering.
What to say in the interview
"The browser parses the URL and checks its caches. If needed it resolves the domain to an IP through DNS, going from local caches to a recursive resolver, root, TLD and authoritative servers. It opens a TCP connection with a three-way handshake, then does a TLS handshake for HTTPS. It sends an HTTP GET, the server or CDN responds, and the browser parses HTML into the DOM, CSS into the CSSOM, runs JavaScript, then does layout and paint. I can go deeper into any step."
Follow-up questions
- What is the difference between a recursive and an iterative DNS query?
- Why does HTTP/3 use UDP?
- What is the critical rendering path?
- What does a CDN change in this flow?
Go deeper
Read these once the basics above feel easy.
Keep-alive lets many requests share one TCP connection. HTTP/2 multiplexes many streams on one connection, which fixes HTTP-level head-of-line blocking, but TCP packet loss still stalls every stream. HTTP/3 over QUIC fixes that because each stream is independent. TLS 1.3 needs one round trip, and resumption can make it zero.
Talk about DNS TTLs and how they affect failover, anycast routing for CDNs, OCSP stapling for certificate checks, HSTS preload lists that force HTTPS before the first request, and how defer, async and preload hints change the order in which the browser fetches and runs scripts.