Repo deep dive
One repository, tens of millions of lines, and a top level that reads as a layer diagram: a standard library, a web engine, a product built on it, and the graphics, network and IPC each of them sits on.
the standard library
Chromium predates most of modern C++, so it grew its own foundation and kept it: callbacks and bind, weak pointers, task runners, values, strings, files, time. Every other directory depends on it, and reading it first makes the rest of the tree stop looking unfamiliar.
base::BindOnce, base::WeakPtr, base::SequencedTaskRunner
the web engine
The multi-process web platform, split along the boundary it enforces: content/browser holds RenderFrameHost, content/renderer holds RenderFrame, and content/public is the narrow API an embedder is allowed to use. content_shell is a working browser built from nothing else.
content/browser/ ⇄ content/renderer/ content/public/ ← the embedder API
the browser itself
Everything that makes Chrome a product rather than an engine: the omnibox, bookmarks, sync, settings, safe browsing, the extension surface, the installer. It is an embedder of content/, structurally no different from the ones Google does not ship.
chrome/browser/ chrome/renderer/ chrome/app/
features between embedders
Features too big for content/ and too shared for chrome/: autofill, password management, translate, metrics, and viz. Each is layered the same way, with its own browser and renderer halves, so Android WebView and other embedders can take a feature without taking the product.
components/autofill/ components/viz/
the rendering engine
The web platform as implemented: core/ for DOM, CSS, layout and paint; platform/ for graphics, fonts and the renderer’s scheduler; modules/ for the specs that are not the core DOM; bindings/ for the V8 glue generated out of Web IDL. It lives under third_party for history — a fork of WebKit — not because it is optional.
blink/renderer/core/ · modules/ · bindings/
the JavaScript engine
Checked out as a dependency and shipped inside the renderer, where Blink drives it through the bindings layer. It has its own release cadence, its own embedders — Node.js among them — and a pipeline of four compile tiers that has nothing to do with the browser around it.
Ignition → Sparkplug → Maglev → TurboFan6 sub-nodes →
the compositor
Chrome Compositor: the layer trees, the tiling and raster scheduling, the animation timelines, and the commit that copies a main-thread tree onto the compositor thread. It knows nothing about the DOM — it takes layers and display lists and produces frames.
cc/trees/layer_tree_host.cc6 sub-nodes →
the message pipes
The IPC system and the bindings generator behind it. Message pipes, data pipes and shared buffers are the primitives; the .mojom compiler turns an interface declaration into typed C++, Java and JavaScript on both ends. It is also usable in-process, which is how a service can be moved without rewriting its callers.
mojo/public/tools/bindings/ → *.mojom
the extracted processes
What used to live in the browser process and now runs on its own: network, storage, audio, device, tracing. Each is defined by its mojom interface rather than by where it happens to run, so the same code can be hosted in-process on a device that cannot afford another one.
services/network/ services/audio/
the network stack
A complete implementation of the wire: sockets and pools, DNS, TLS, the HTTP cache, cookies, proxy resolution, and QUIC — which was written here before it was a standard. Most callers now reach it through the network service rather than linking it directly.
net::URLRequest · net/quic/ · net/http/
the command buffer
The mechanism that lets an untrusted process use the GPU. The client side records commands into shared memory; the service side, in the GPU process, validates every one before touching a driver. Same idea underneath WebGL, WebGPU and the browser’s own drawing.
gpu/command_buffer/client/ ⇄ service/
the native toolkit
Not the web platform — the browser’s own interface. ui/gfx has geometry, colour and text; ui/views is the widget toolkit the desktop UI is built from; ui/aura is the window system underneath it. Chrome draws its own chrome rather than using the platform’s.
ui/views/ ui/gfx/ ui/aura/
one per platform
The sandbox is not one design but the strictest thing each operating system will allow. seccomp-bpf and namespaces on Linux, restricted tokens with job objects and win32k lockdown on Windows, Seatbelt profiles on macOS. Same guarantee, three unrelated implementations.
sandbox/linux/ sandbox/win/ sandbox/mac/
how it is assembled
Tens of millions of lines will not build with a naive system. gclient fetches the tree and its hundreds of dependencies, GN evaluates BUILD.gn files into a Ninja graph, and Ninja does the work. The build configuration is genuinely part of the architecture — component builds, target OS, and feature flags all resolve here.
gclient sync → gn gen out/Default
→ autoninja -C out/Default chrome