Chromium · Multi-process architecture
Chrome is not one program but a small operating system of them: one privileged browser process coordinating a fleet of sandboxed ones. The split is a security decision first and a stability decision second — a tab crashing takes down a process the browser can simply replace.
the privileged one
There is exactly one, and it owns everything the operating system trusts you with: the window, the profile on disk, the cookies, the tabs. It is the only unsandboxed process, because it is the thing enforcing the sandbox on everybody else. When it dies, the browser dies.
content/browser/ → RenderFrameHost
the untrusted one
Many of them, one per site, each running Blink and V8 behind a sandbox with no file system and no sockets of its own. This is where every byte you did not write gets parsed and executed. Anything it needs from the outside world it has to ask the browser process for.
content/renderer/ → RenderFrame
the driver boundary
The only process allowed to call the graphics driver. Renderers write commands into a buffer, and this process validates and replays them. Graphics drivers are large, vendor-specific and historically fragile — putting one behind a process boundary means a driver crash loses your tabs’ pixels, not your session.
gpu/command_buffer/ → validate, then replay
sockets, TLS, cache
The network stack moved out of the browser process into a service of its own: sockets, TLS, the HTTP cache, cookie access. A bug in a protocol parser is then a bug in a replaceable process rather than in the one holding your profile.
services/network/
one job, then gone
A short-lived sandboxed process spun up per risky job — decoding an image, parsing a media container, unpacking an extension. The standing assumption is that any format parser handed hostile input will eventually be wrong, so it is given a box it can be wrong inside.
content/utility/ → launch, run, exit
Linux and Android only
A process forked early, before anything interesting is loaded, and kept warm. Every new renderer forks from it, inheriting an already-linked binary and its initialised state, so opening a tab does not pay for dynamic linking again. Windows and macOS launch fresh processes instead.
fork() → renderer, already linked