How Browsers Work - URL to Pixels

A browser starts by fetching bytes from the internet and ends by drawing pixels on your screen. What makes it powerful is everything in the middle: parsing, runtime execution, security rules, scheduling, and rendering.

End-to-end flow

Key terms in simple language

• URL: the web address you open.
• DNS: converts a domain name into a server address.
• TLS: encrypts traffic between browser and server.
• HTTP: the request/response protocol used for web content.
• Content-Type: tells the browser how to treat incoming bytes.
• DOM: the in-memory page structure.
• CSSOM: the in-memory style rule structure.
• Render tree: the visible part of page structure plus styles.
• Layout: calculates position and size of elements.
• Paint: turns layout into drawing instructions.
• Compositor: assembles layers into frames.
• GPU: helps render frames efficiently.
• Event loop: coordinates what runs next on the main thread.

window and document

• window is the global runtime container for one tab/frame.
• document is the page structure currently loaded in that container.
• document is available as window.document.

Think of it like this:

• window is the room.
• document is the whiteboard inside the room.

Each tab has its own room and whiteboard. Each iframe also gets its own smaller room and whiteboard.

Where HTML, CSS, JS, and WASM fit

• HTML creates the page structure.
• CSS controls how that structure looks.
• JavaScript updates behavior, state, and interactions.
• WebAssembly handles heavy computation and usually hands results back through JavaScript.

WebAssembly is fast for compute, but page updates still flow through browser APIs used by JavaScript.

V8 and ownership boundaries

• V8 runs JavaScript and WebAssembly code.
• Page parsing (HTML/CSS), DOM implementation, layout, and painting are handled by the browser engine layer.
• Network work (DNS/TLS/HTTP/cache handling) is done by browser networking components.
• Final pixel composition is done by compositor and GPU components.

In Chromium browsers:

• V8: script execution.
• Blink: page model, web platform APIs, layout/paint pipeline.

Other browsers use equivalent pairs:

• Firefox: Gecko + SpiderMonkey
• Safari: WebKit + JavaScriptCore

Node.js uses V8 too, but it is not a browser host, so it does not provide a page model like window and document by default.

Debugging checklist by layer

1. Nothing renders: verify status code and Content-Type first.
2. Script problems: verify script type, load mode, policy restrictions, and cross-origin rules.
3. Style problems: verify CSS path, response type, and load order.
4. State mismatch across tabs: verify storage scope and navigation cache behavior.
5. Jank: profile long main-thread tasks and expensive layout/paint work.

Sticky takeaway

When debugging browser issues, classify them into one layer first: network, parser, runtime, policy, or renderer. That single step usually cuts investigation time a lot.