Anatomy of a Browser

From a URL to pixels, and from a click back to code20 min readJust now--Type a URL, press Enter, and a page appears.A browser is one of the most complicated softwares on your computer. It resolves names, negotiates encrypted connections, speaks several network protocols, executes untrusted programs, calculates two-dimensional geometry, drives the GPU, stores persistent data, exposes accessibility information, and tries to keep mutually hostile websites isolated, all while responding to input within a few milliseconds.This article digs into the internal mechanism of a browser. We will follow one navigation from the address bar to the screen, then examine what happens when the user interacts with the page. The goal is not to memorize the internals of Chrome, Firefox, or Safari. Their implementations differ. The goal is to learn the shared problems every browser engine must solve and the architectures that connect those problems.Index1. What is a browser?2. Overview of major subsystems3. Navigation4. Finding and connecting to the server5. From bytes to a document: HTML parsing6. CSS: from rules to computed values7. Layout: turning styles into geometry8. Paint: turning geometry into drawing commands9. Rasterization and compositing: producing pixels10. JavaScript: the page becomes a program11. The event loop: coordinating asynchronous work12. From a physical click to a DOM event13. Processes and threads14. Security15. Storage, state, and identity16. What changes when the page changes?17. The complete workflow18. Further reading1. What is a browser?At first approximation, a browser is a program that turns web resources into interactive documents.URLs + bytes + user input ↓ an interactive page ↓ pixels + audio + network effects + stored stateA browser is several systems combined:A user agent that navigates URLs and implements web standards.A network client for HTTP, HTTPS, WebSocket, WebTransport.A document engine that parses HTML and CSS into structured data.A programming runtime that executes JavaScript and WebAssembly.A rendering engine to compute styles, lay out boxes, and paint them,A security boundary that runs code from mutually distrustful origins.A storage system for cookies, caches, local storage, IndexedDB, permissions, and credentials.An application shell with tabs, history, bookmarks, downloads, settings, and developer tools.People often use several terms interchangeably, but the distinctions help:Press enter or click to view image in full sizeA browser engine is not simply a linear HTML-to-image converter. The page can modify itself while it is being parsed. CSS can load fonts and images. JavaScript can trigger networking, change the DOM, measure layout, and change it again. An iframe may belong to another security origin and even another process. Scrolling may proceed on a compositor thread while the main thread is busy.2. Overview of major subsystemsA useful conceptual architecture looks like this:Browser UI └─ Navigation and permissions └─ Network stack and caches └─ Document loader ├─ HTML parser ───────────────→ DOM ├─ CSS parser ────────────────→ style rules └─ JavaScript engine ↔ Web APIs ↓ computed style ↓ layout ↓ paint/display list ↓ rasterization/compositing ↓ pixelsThis is a conceptual dependency graph, and real browsers split the work across processes and threads. Nor does every stage wait for the previous one to finish. HTML is normally parsed as it arrives, subresources are discovered early, images may decode off the main thread, and the compositor can reuse old rasterized content.3. NavigationSuppose the user enters:https://example.com/articles/browser?q=rendering#layoutThe browser first decides what the input means. Is it a URL, a search query, a bookmark keyword, or an internal command? Once it chooses navigation, it parses and normalizes the URL into components:scheme: httpshost: example.comport: 443 (implicit)path: /articles/browserquery: q=renderingfragment: layout # fragment is not sent in the request, and # the browser may use it after loading to # scroll to an elememnt or text fragmentBefore contacting the server, the browser considers policy and state:Is the scheme supported?Should an HSTS rule upgrade http to https?Is the URL blocked by enterprise policy, parental controls, an extension, or Safe Browsing?Can an existing tab or installed application handle it?Is there a valid cached response?Does a service worker control this navigation?Are usable DNS, TLS, or HTTP connections already available?Navigation is therefore not synonymous with “send a GET request.” It is a state machine that can redirect, fail, download a file, display an error page, hand control to another application, or commit a new document.The navigation lifecycleA simplified lifecycle is:Initiate: receive a user action or script request.Resolve policy: apply security, download, popup, and embedder rules.Fetch: obtain a response, possibly through a service worker or cache.Follow redirects: update the URL and repeat relevant checks.Determine content: inspect status, headers, and media type.Commit: replace the current document with a new one.Load: stream bytes into the appropriate parser or viewer.Finish or continue: the main document may finish while subresources and application activity continue indefinitely.Before commit, the old page is usually still displayed. At commit, the browser associates the navigation with a new document, history entry, origin, and renderer context. A network error before commit can leave the old page intact; a failure afterward belongs to the new document.4. Finding and connecting to the serverFor a network fetch, the browser needs an endpoint and a secure transport.4.1 Name resolutionThe hostname example.com must be mapped to one or more IP addresses. Resolution may consult:the browser’s own DNS cache;the operating system resolver and hosts file;a configured DNS server;DNS over HTTPS or DNS over TLS;previously learned HTTPS/SVCB records that advertise protocol endpoints.The result can contain IPv4 and IPv6 addresses. A browser may race or stagger connection attempts so a broken network path does not impose a long delay.DNS is not merely a dictionary lookup. Records expire; aliases form chains; different networks return different answers; private and public address spaces have security implications; and resolution itself may need encryption and policy enforcement.4.2 Establishing transportFor HTTPS, the common choices are:HTTP/1.1 or HTTP/2 over TCP and TLSHTTP/3 over QUIC, which integrates secure transport over UDPWith TCP, the client and server establish a reliable byte stream. TLS then authenticates the server and negotiates encryption. During the TLS handshake, the browser validates the certificate chain, hostname, validity period, key usage, revocation-related signals, and local trust policy. It also negotiates an application protocol such as HTTP/2 using ALPN.QUIC combines transport and cryptographic negotiation more tightly and supports multiple independent streams without TCP’s cross-stream head-of-line blocking.Regardless of protocol, the browser tries to reuse connections because DNS, transport, and cryptographic handshakes cost round trips.4.3 Sending HTTPA conceptual request might look like:GET /articles/browser?q=rendering HTTP/1.1Host: example.comAccept: text/html,application/xhtml+xmlAccept-Encoding: gzip, br, zstdCookie: session=...User-Agent: ...The exact wire representation differs for HTTP/2 and HTTP/3, which compress headers and multiplex streams. The browser also adds context such as cache validators, referrer information, fetch metadata, priorities, and credentials according to the request mode and policy.The response might begin:HTTP/1.1 200 OKContent-Type: text/html; charset=utf-8Content-Encoding: brCache-Control: max-age=300Content-Security-Policy: default-src 'self'...compressed HTML bytes...The network stack decodes the transfer and content encodings, processes headers, updates cookies and caches where permitted, and streams the body toward the document loader. It does not need to wait for the entire file.4.4 Caches are part of the algorithmBrowsers contain several kinds of reusable state:DNS and connection cachesHTTP response cachepreloaded or prefetched resourcesservice-worker-controlled cachesdecoded image cachefont cachecompiled JavaScript or WebAssembly code cacheback/forward cache, which can preserve a whole document and its JavaScript heapAn HTTP cache entry can be fresh, in which case it may be reused immediately, or stale, in which case the browser may revalidate it using headers such as If-None-Match. A 304 Not Modified response reuses the stored body while refreshing metadata.4.5 Service workers can interposeA service worker is an origin-scoped worker that can receive fetch events for controlled pages. It may:return a cached response;synthesize a response;modify or forward a request;try the network and fall back to offline content.This makes a web application programmable at a point that resembles a local proxy, but within strict origin, lifecycle, and security rules.5. From bytes to a document: HTML parsingOnce the browser commits an HTML response, the renderer begins converting a byte stream into a Document.5.1 Decoding bytes into charactersHTML arrives as bytes, and the browser determines an encoding from signals such as a byte-order mark, the Content-Type header, an early <meta charset>,