Chromium is the open-source browser project that supplies the code base for Google Chrome and for many other browsers, including Microsoft Edge, Opera, Brave and Vivaldi. Among browser technologies it is the most widely deployed foundation, combining the Blink rendering engine, the V8 JavaScript engine, a multi-process architecture and a strict sandbox.
Chromium is both a buildable browser and a shared platform. Vendors take its source, add their own services, branding and features, and ship the result as a separate product. This makes Chromium the reference point for how a large share of the web is rendered and executed.
How the Chromium architecture works
Chromium uses a multi-process architecture in which separate operating-system processes handle different jobs. A single browser process manages the user interface, navigation, storage and permissions, while renderer processes parse HTML and CSS, run JavaScript and paint pages. A GPU process handles compositing and graphics, and a network service performs HTTP, TLS and caching.
Since the introduction of site isolation, documents from different sites are placed in separate renderer processes. This design limits the damage of a compromised renderer and mitigates side-channel attacks such as Spectre, at the cost of higher memory consumption than a single-process design.
Each renderer runs inside the browser sandbox, which uses operating-system mechanisms such as restricted tokens on Windows, seccomp-bpf filters on Linux and the Seatbelt profile on macOS. A renderer therefore cannot open files, start programs or reach the network directly; it must ask the browser process through Mojo IPC, which checks each request against the security policy before acting on it.
The table below lists the main components and the role each one plays inside a running Chromium browser.
| Component | Function | Runs in |
|---|---|---|
| Blink | Parses HTML and CSS, computes layout and paints | Renderer process |
| V8 | Compiles and executes JavaScript and WebAssembly | Renderer process |
| Skia | 2D graphics library for drawing pages | Renderer and GPU processes |
| Network service | HTTP, QUIC, TLS, cookies and HTTP cache | Dedicated utility process |
| Sandbox | Restricts system access of untrusted processes | All renderer and utility processes |
| Browser UI and Mojo IPC | User interface and messaging between processes | Browser process |
Release channels and versioning
Chromium development follows a regular release train. A new major version reaches the stable channel roughly every four weeks, and each version passes through Canary, Dev and Beta stages before release. Chromium itself has no official stable binary; the stable channels belong to the browsers built from it.
| Channel | Update frequency | Typical audience |
|---|---|---|
| Canary | Daily builds | Developers testing the newest code |
| Dev | About weekly | Early adopters and web developers |
| Beta | About weekly, one version ahead | Testers checking upcoming features |
| Stable | Major version about every four weeks | General users |
| Extended Stable | Major version about every eight weeks | Managed enterprise environments |
Security fixes arrive between major versions. Downstream browsers usually rebase onto new Chromium versions within days or weeks, so the speed at which a vendor follows upstream directly affects how quickly its users receive patches.
Chromium compared with Chrome and other engines
The difference between Chromium and Chrome is a matter of additions, not of engine. Chrome adds proprietary components on top of Chromium, such as automatic updates, Google account sync, licensed media codecs, crash reporting and certain DRM support. The rendering and JavaScript behavior are the same.
| Project | Rendering engine | JavaScript engine | Main browsers |
|---|---|---|---|
| Chromium | Blink | V8 | Chrome, Edge, Opera, Brave, Vivaldi |
| WebKit | WebKit | JavaScriptCore | Safari and all iOS browsers |
| Gecko | Gecko | SpiderMonkey | Firefox and its derivatives |
Blink began in 2013 as a fork of WebKit, so the two engines share history but have diverged significantly. Because most desktop and Android users run Chromium-based browsers, the project has strong influence on which web platform features ship first, which is why standards discussions often weigh Chromium implementation status alongside WebKit and Gecko.
Where Chromium is used beyond browsers
Chromium code powers many products that are not general-purpose browsers. Its embeddable components make it a common choice wherever an application needs a modern web runtime.
- Electron bundles Chromium with Node.js to run desktop applications written in web technologies.
- Chromium Embedded Framework lets native applications host web content inside their own windows.
- Android System WebView is based on Chromium and renders web content inside Android apps.
- Headless Chromium runs without a visible window and drives automated testing, screenshots and PDF generation through tools such as Puppeteer and Playwright.
- ChromeOS uses the Chrome browser, built from Chromium, as its primary user interface.
This reach has a practical consequence for developers: testing in one Chromium-based browser covers a large share of rendering behavior, but not differences in vendor features, codecs, extension policies or default privacy settings.
Practical considerations and common misconceptions
Several misunderstandings about Chromium recur among users and developers. Clarifying them helps teams make sound testing and deployment decisions.
| Misconception | Reality | Practical consequence |
|---|---|---|
| Chromium is just Chrome without branding | Chrome adds codecs, updates and services | Media playback can differ between them |
| Raw Chromium builds update themselves | Many builds have no automatic updater | Unpatched installs fall behind on security fixes |
| All Chromium browsers behave identically | Vendors change defaults, flags and features | Test critical flows in more than one of them |
| Testing in Chromium covers the whole web | WebKit and Gecko differ in many details | Cross-browser testing remains necessary |
The most important operational risk is patch latency. Vulnerabilities in V8 or Blink are disclosed upstream, and any product that embeds an old Chromium version, such as an outdated Electron application, remains exposed until it is rebuilt. Teams that ship Chromium-based software should track upstream security releases as part of routine maintenance.
In everyday language
Chromium is the shared engine that many popular web browsers are built on. Think of it as a car platform used by several brands: Chrome, Edge, Opera and Brave look different and add their own extras, but underneath they share the same motor and chassis.
Because the engine is open source, anyone can study it or build a browser from it. That is why so many browsers display websites in nearly the same way.
Seen in the real world
A software company sells a desktop note-taking application built with Electron, which bundles a specific Chromium version. A security advisory reports a critical V8 flaw that is already fixed in the current stable release. The company’s application still ships a Chromium build that is three major versions old.
The engineering team upgrades Electron, which pulls in the patched Chromium, runs its automated Playwright test suite against the new build and releases an update within a week. Users are protected only once the bundled engine is replaced, which leads the team to schedule an Electron upgrade with every Chromium security release instead of updating only when new features are needed.