Chromium engineering
What is Chromium? A practical guide for browser development teams
By Usman Khan, Lead Chromium Developer
Technically reviewed by Ahmed Raza, Head of Browser Development
Published Last updated 9 min read
If your team is planning a browser product, you will hear the word Chromium early. Some people treat it as a browser, some as an engine, and some assume it is Chrome without the logo. It is none of those exactly. Chromium is Google’s open-source browser project, and knowing where its boundaries are decides what your team will build and maintain.
What Chromium is
Chromium is an open-source browser project. Google leads it, and other companies and individuals contribute to it. The codebase, roughly 35 million lines, covers rendering, networking, JavaScript execution, browser UI, security sandboxing and a multi-process architecture.
Three names come up most often when people describe its internals:
- Blink is the rendering engine. It parses HTML and CSS, lays out pages and paints them. Google forked it from WebKit in 2013.
- V8 is the JavaScript and WebAssembly engine. It also runs outside browsers, for example in Node.js.
- Content is the module that provides the core multi-process browsing model: browser, renderer and other processes, plus the APIs an embedder uses to host web content.
In simple terms, Chromium is the public engineering base. Vendors build products on top of it, add integrations, apply branding and ship their own browsers.
Is Chromium open source?
Yes. Chromium is developed in public repositories with open issue tracking and code review, and its own code is released under a BSD-style license. It also bundles third-party libraries that carry their own licenses, so a license review of what you ship is part of any product plan.
Open source does not mean easy. Chromium is one of the largest software projects in the world, so a clear strategy, build tooling and a long-term maintenance plan are essential.
Chromium vs Chrome
Chrome is Google’s product built from Chromium. Chromium provides the base; Chrome adds Google’s services, licensed components and release process. The main differences:
| Area | Chromium | Google Chrome |
|---|---|---|
| Governance | Open-source project led by Google | Google product built from Chromium |
| License | BSD-style, plus third-party component licenses | Free to download, with proprietary components under Google’s terms |
| Branding | Neutral name and logo | Google branding and logo |
| Google services | Not included. Chrome Sync and other private Google APIs have been closed to third-party builds since March 2021 | Google sign-in, Chrome Sync and other Google integrations |
| Codecs and DRM | Default builds leave out proprietary codecs such as H.264 and AAC; Widevine DRM needs an agreement with Google | Ships proprietary codecs and the Widevine DRM module |
| Updates and crash reports | You build, sign and deliver updates, and run your own crash reporting | Google’s updater and crash reporting |
When you build on Chromium, you own everything Chrome would normally add for you, including update delivery, crash reporting and any codec or DRM licensing your product needs.
How a Chromium-based browser is layered
A custom browser is not a single codebase you rewrite. It is a stack in which most layers stay close to upstream and your product sits on top. Keeping that boundary clear is what keeps later upgrades manageable.
Product features and browser UI
- C++
- WebUI
Your toolbar, settings pages, onboarding, policies, branding and any custom features. The Chrome UI layer is the usual starting point to build on or replace.
Content module and embedder APIs
The multi-process browsing model: browser process, renderer processes and the APIs an embedder uses to host web content.
Blink and V8
Blink renders web pages. V8 executes JavaScript and WebAssembly. Both are usually kept as close to upstream as possible.
Networking and storage
The network stack, TLS, caching, cookies and profile storage. A common place for privacy or proxy-related changes.
Sandbox and process isolation
OS-level sandboxing that restricts what renderer processes can do. Changes here are security sensitive.
Operating system and build pipeline
- Windows
- macOS
- Linux
Windows, macOS, Linux and other targets, plus signing, packaging and update delivery.
- Your product
- Upstream: third-party code we build on
- Platforms and release
Well-known Chromium-based browsers
Many browsers you may already use share this foundation. Google Chrome itself is built on Chromium. Others include:
- Microsoft Edge: Microsoft’s browser, rebuilt on Chromium in 2020 in place of its own EdgeHTML engine, with Microsoft services and enterprise management added.
- Brave: builds privacy features such as Shields content blocking into the browser. Its own code is open source.
- Opera: moved from its own Presto engine to Chromium in 2013, and adds interface features such as a sidebar.
- Vivaldi: focused on interface customization, built on Chromium with its own UI layer.
Most of these replace large parts of the browser UI and services while keeping the engine close to upstream. That pattern, a heavily customized shell on a mostly upstream core, is the one most custom browser projects follow. Edge and Opera are proprietary: you can build on the same Chromium base, but not on their code. Brave is open source and can be forked.
Why teams choose Chromium for custom browser development
- Web compatibility: broad support for modern web apps and front-end stacks, which reduces the risk that sites break in your product.
- Widely deployed engines: the same rendering and JavaScript engines run in Chrome, Edge, Brave, Opera and many other browsers.
- Extensibility: room for source-level changes, policy controls and specialized UX flows.
- Familiar tooling: more engineers know Chromium tooling than niche browser stacks, which can help with hiring and onboarding.
When Firefox is the better base
Firefox’s Gecko engine is the main open-source alternative. Teams choose it when they want an engine that Google does not control, when Firefox’s extension model fits better (Firefox still supports Manifest V2 and blocking webRequest), or when they want to follow Firefox’s Extended Support Release (ESR), a longer-lived branch that keeps receiving security fixes. Tor Browser, for example, is built on Firefox ESR. Firefox’s code is under the Mozilla Public License 2.0, which requires you to publish your changes to MPL-licensed files you distribute. See our Firefox browser modification service.
Custom browser, embedded browser, Electron app or extension?
“Building on Chromium” covers several very different scopes. The right one depends on how much of the browser experience you need to control. Our page on Chromium browser development covers the full-fork case, and embedded browser development covers hosting web content inside your own application.
| Approach | What you control | Typical fit | Main maintenance cost |
|---|---|---|---|
| Custom Chromium browser (fork) | Browser UI, network behavior, privacy features, policies and branding | A standalone browser product with its own identity | Rebasing patches and shipping security updates on each upstream release you follow |
| Embedded browser (CEF or similar) | Web content inside your native application, with a limited browser UI | Desktop apps that need a full web engine inside a native shell | Updating the embedded framework and testing your integration |
| Electron app | A desktop app built with web technologies, bundling Chromium and Node.js | Cross-platform desktop apps built by web teams | Keeping the Electron version current for security fixes |
| Browser extension | Features added inside an existing browser through extension APIs | Functionality that fits within the limits of the extension platform | Following extension API and policy changes in each browser |
Ask three questions to narrow it down. Do users need a browser with its own identity, or a feature inside an app they already use? Do you need behavior that extension APIs do not allow, such as network stack changes or browser UI internals? Can you commit engineering time to upstream updates for the product’s whole lifetime?
For each option in more depth, see our guides on CEF, WebView2 and WKWebView, Electron vs Tauri, Manifest V3 extensions and what a custom browser costs.
What keeping a Chromium fork healthy involves
Forking is the easy part. The ongoing work is keeping your changes compatible with an upstream project that moves quickly and ships security fixes between releases. That means keeping your changes as a small, documented patch series, rebasing onto the versions you follow, shipping security fixes quickly, and owning the build system: GN to generate build files, Siso or Ninja to run them, plus CI and code signing for each platform. Our version porting playbook covers the process step by step, and our version porting service does the work.
What to plan before starting a Chromium-based product
- Target operating systems and release channels, and whether mobile is in scope.
- Scope of browser modifications versus extension-level customization.
- An upgrade strategy for future Chromium versions, and who owns security patches and updates.
- Licensing for codecs, DRM and any Google services you plan to use.
- A QA matrix across versions, policies and enterprise environments.
To see how these decisions play out in practice, browse our browser projects, including the GTX Browser and Kahf Browser case studies. For help scoping your own project before committing to a build, see our browser engineering consulting service.
Final takeaway
Build on Chromium when the browser itself is your product and you can fund regular rebases for as long as it ships. If not, an extension or an embedded browser costs less. Make the architecture and maintenance decisions early, and Chromium gives you a solid base for a browser of your own.
Frequently asked questions
Is Chromium the same as Google Chrome?
No. Chrome is Google’s product built from Chromium. Chrome adds Google sign-in and Sync, the Widevine DRM module, proprietary codecs such as H.264 and AAC, Google’s updater and crash reporting, and Google branding. Browsers that other companies build from Chromium cannot use Chrome Sync or other private Google APIs.
Is Chromium free to use commercially?
In general, yes. Chromium’s own code is under a BSD-style license that allows commercial use and modification, as long as you keep the license notices. It bundles third-party components with their own licenses, and Widevine DRM and Google APIs need separate agreements, so review the licenses of what you ship.
How often does a Chromium fork need to be updated?
Chrome ships a new major version every two weeks (since Chrome 153 in September 2026), with security fixes in between. A fork in production either rebases on each release, or follows Chrome’s Extended Stable milestones, which move every eight weeks and still receive security fixes, and backports urgent fixes in between.
What skills does a Chromium browser project need?
Mostly C++, plus Chromium’s build tooling (GN, and Siso or Ninja), the platform APIs of each target operating system, release engineering and security response. Front-end skills matter for WebUI pages and extensions, but they rarely cover the whole scope of a fork.
Can a Chromium-based browser support Chrome extensions?
Yes. Chromium includes the extension system, and a Chromium-based browser can install extensions from the Chrome Web Store, as Brave and Vivaldi do. Chrome has removed Manifest V2 support, so a Chromium-based browser runs Manifest V3 extensions unless you carry your own patches to keep MV2 working.
Planning a Chromium-based product?
If you are deciding between an extension, an embedded browser and a full Chromium fork, we can help you choose. See our Chromium browser development and consulting services.