Browsers are the most complex engines on the planet, yet for daily users the experience feels instantaneous. This interactive guide was written for engineers, designers, and anyone who spends time on the web and wants a clear mental model of how a browser processes a request, turns it into a document, and renders pixels on the screen. ## A Journey that Begins with a URL The address bar is the starting point of every navigation. When you type “pizza”, the browser translates that plain text into a search URL—typically `https://google.com/search?q=pizza`—and the same happens for “duckduckgo.com”. A proper hostname such as `example.com` is normalised to `https://example.com`. The guide lets you experiment by typing free‑form input and instantly seeing the generated URL. ## From URL to HTTP Request Once the browser knows the target URL it needs to fetch the resource. Browsers use the HTTP protocol, which expresses a request as a series of headers and a path. For instance: ``` GET / HTTP/1.1 Host: example.com Accept: text/html ``` The Host header tells the server which virtual host the client intends to reach. The guide demonstrates how the URL is mapped to an HTTP verb and headers before the request leaves the client. ## Resolving the Server Address via DNS Names such as `example.com` cannot be sent directly over the network. The browser queries the DNS system to translate a domain into an IPv4 or IPv6 address. The interactive simulation lets you type a hostname and watch the resolver return an IP, highlighting the DNS query exchange. ## Establishing a Reliable Transport: TCP Three‑Way Handshake Once the IP is known, the browser must secure a reliable conduit to the server. TCP implements this via a three‑step handshake: 1. **SYN** – the client sends a SYN packet with a random sequence number 2. **SYN‑ACK** – the server acknowledges and provides its own sequence number 3. **ACK** – the client confirms, and the connection is now *established*. The guide uses visual packets to show how sequence and acknowledgement numbers maintain order and guarantee delivery, even when packet loss occurs. ## Sending and Receiving HTTP Data With TCP in place, the browser sends the previously constructed HTTP request. The server replies with a status line, set of headers, and a body that typically contains HTML. The simulation displays the full round‑trip, allowing you to interrupt the network and observe retransmission and error handling. ## Parsing HTML into a DOM Tree The raw HTML body is fed into an HTML parser that tokenises tags, attributes, and text. It constructs a Document Object Model (DOM) tree, a hierarchical in‑memory representation of the document. The guide visualises this process step‑by‑step: the parser emits start tags, builds elements, and inserts missing tags to keep the tree valid. Example: ```

Example Domain

An example paragraph.

An example link

``` During parsing the DOM becomes available for JavaScript. Editing the accompanying script in the guide demonstrates how `document.querySelector` and live‑style changes immediately reflect in the tree. ## Constructing the Render Tree and Painting the Screen After a stable DOM is built, the browser merges it with CSS rules (computed style) to produce the *render tree*. Each node in this tree knows its dimensions and visual properties. The rendering pipeline then runs: 1. **Layout (Reflow)** – calculates the size and position of each element 2. **Paint** – fills pixels for each box, respecting colors, gradients, borders, etc. 3. **Composite** – layers painted quads onto the GPU, combining visual elements into the final frame. The guide allows you to tweak CSS properties, such as changing a widget’s width, and immediately see which stages repeat. Small colour changes require only repaint, while a structural change forces layout and repaint, explaining why layout‑heavy pages feel sluggish. ## When It All Comes Together The interactive series covers the end‑to‑end flow: from a fuzzy query in the address bar, through DNS resolution, TCP handshakes, HTTP exchange, parsing, DOM construction, and the rendering pipeline. It keeps the focus tight by omitting higher‑level details such as TLS handshakes, HTTP/2 multiplexing, or DNS caching, so you have a manageable mental model that you can build upon. Feel free to fork the open‑source repository, propose improvements, or contribute new interactive experiments. With this guide, you should be able to explain, to yourself or to colleagues, how a typed URL becomes an interactive web page rendered in milliseconds. --- Thank you for exploring the internals of web browsers. Happy hacking!