Why Chromium Built a Custom Multi-Process Architecture

This article explores the fundamental reasons why the Chromium engineering team abandoned traditional single-process browser designs in favor of a custom multi-process architecture. As websites evolved from static documents into complex, interactive applications, older browser designs struggled to keep up with the demands of the modern web. By isolating web pages and browser components into separate operating system processes, the Chromium team achieved massive improvements in stability, performance, and security, ultimately setting a new standard for how web browsers are built.

The Limitations of Single-Process Designs

When early web browsers were created, web pages were mostly static text and images. Running the entire browser—including the user interface, network requests, layout rendering, and JavaScript execution—inside a single operating system process made sense. It was simple to build and used minimal system memory.

However, by the mid-2000s, websites had transformed into full-fledged software applications. Running multiple complex web apps inside a single process created a massive bottleneck. A flaw in just one website could compromise the entire browser, leading the Chromium team to realize that a single-process design was no longer viable.

Crash Isolation and Stability

In a single-process browser, all open tabs share the same process and memory space. If a poorly coded website causes a fatal error in the rendering engine or the JavaScript engine, the entire browser crashes immediately. Users lose all their open tabs and unsaved work at once.

Chromium solved this by acting like an operating system. Just as an OS separates different applications into distinct processes so one crashing app doesn't freeze the whole computer, Chromium places different web pages into separate "renderer" processes. If a web application crashes in Chromium, only that specific renderer process dies. The user sees a "Sad Tab" icon on the affected page, while the main browser interface and all other open tabs continue running smoothly.

Performance and Responsiveness

Single-process browsers often suffered from "jank" or completely frozen interfaces. Because all tabs shared the same main thread, a heavy JavaScript calculation running in a background tab could freeze the user's scrolling in the foreground tab, or even lock up the browser's back button and address bar.

With a multi-process architecture, Chromium runs the main browser UI in its own dedicated process, while web pages run in separate processes in the background. If a web page gets stuck in an infinite loop, the user can still effortlessly switch tabs, scroll other pages, or simply close the frozen tab. Furthermore, this design allowed Chromium to take full advantage of modern multi-core processors, running multiple tabs in parallel across different CPU cores.

Clean Memory Management

Single-process browsers were notorious for memory leaks. Over a long browsing session, opening and closing dozens of tabs would cause the browser's memory usage to bloat. Even after tabs were closed, the fragmented memory was rarely returned to the operating system completely, forcing users to restart their browsers to speed up their computers.

In Chromium's multi-process model, memory management is drastically simplified. Because each tab (or group of connected tabs) runs in its own process, closing a tab terminates that specific process. When a process is terminated, the operating system instantly and completely reclaims every byte of memory that the tab was using, eliminating long-term memory bloat.

Security Through Sandboxing

Web browsers constantly download and execute untrusted code from all over the internet. The rendering engine, which parses HTML, CSS, and JavaScript, is massive, complex, and virtually impossible to make 100% bug-free. In a single-process browser, the rendering engine has the exact same system permissions as the browser itself. If an attacker exploits a bug in the rendering engine, they immediately gain the ability to read files on the user's hard drive, install malware, or access the network.

The Chromium team utilized their multi-process design to implement a strict "sandbox." The main browser process has full access to the operating system, network, and user files, but it never directly processes untrusted web code. Instead, untrusted code is handled exclusively inside the isolated renderer processes. Chromium strips these renderer processes of almost all system privileges. Even if a malicious website successfully hacks a renderer process, it is trapped inside the sandbox—it cannot read the user's hard drive, access the webcam, or interact with the operating system without going through the heavily guarded main browser process.