Chromium vs Chrome: same source, different browser

Chromium is the code; Chrome is one company's build of it. Google develops Chromium in the open, then compiles it with a few things that only Google ships, puts its logo on it and calls that Google Chrome. Edge, Brave, Opera and Vivaldi are other companies' builds of the same source.

Chromium vs Chrome: what Google adds

Chromium's own documentation lists the differences, written for Linux packages (Chromium docs, read 2 November 2026). Chrome carries the H.264 video codec and the AAC audio codec; Chromium carries AV1, VP8, VP9, MP3, Opus and the other open formats. Chrome reports crashes and usage metrics only if you turn them on, and Chromium never does. Chrome has Google's API keys built in, and its releases are tested by Google before they reach users. In a Chromium package from a Linux distribution, the keys, the sandbox and the testing all depend on whoever packaged it.

For browsing, the two are close enough that most people would never notice. For fingerprinting, the list above is incomplete, because it describes what a user sees and not what a page can read.

How it works: Its own Chromium

What a page can read

We build our own Chromium, so we have measured this against the machine's own Google Chrome, on one Mac, same major version. Three differences stood out, and none of them is on the official list.

The speech voice list is the largest. speechSynthesis.getVoices() returns 199 voices on branded Chrome and 180 on any unbranded build. The missing 19 are the Google … network voices, supplied by a component that is compiled in only when the build is Chrome-branded. One call reads the whole list, so a browser whose User-Agent says Chrome and whose voice list says Chromium has identified itself.

The second is field trials. An unbranded Chromium compiles a testing configuration into the binary and runs it at every launch, so it switches on experiments no Google Chrome has. Against Chrome 153 that was 20 differences in which web APIs exist: no navigator.runAdAuction, no Document.browsingTopics, no window.XSLTProcessor, and window.ModelContext present where Chrome does not have it. An API a page finds on one browser and not the other is not a weak signal.

The third is DRM. Widevine keeps a device's client ID private only for a browser carrying Google's signatures. Without them, the first licence request carries a per-install device certificate in the clear: 1704 bytes where branded Chrome sends 2. That certificate is the same for every profile on the machine, which makes it a join key between accounts.

Why it matters for a browser fingerprint

A detector does not ask "is this Chrome?" once. It reads the User-Agent and client hints, which claim Chrome, then reads surfaces like the three above, which answer for themselves. When the claim and the answers disagree, the browser fingerprint is inconsistent, and inconsistency is a louder signal than rarity. The same check runs one layer lower, on the TLS handshake (TLS fingerprinting covers that layer, where Chromium and Chrome turn out identical).

How Mosaic handles it

Mosaic's engine, Tesseract Chrome, is built from stock Chromium source with our patch series on top, so by default it would be an unbranded Chromium with all three gaps. We close them one by one. A patch restores the 19 Google … voices where Chrome's own component would supply them. Every launch passes --disable-field-trial-config, which removed all 20 API differences in our measurement. Widevine is off unless a profile asks for it, because we cannot carry Google's signature and the certificate would link every profile together. Why we patch the source at all, rather than wrapping a stock browser, is the story in why we built our own Chromium, and the engine page lists what Tesseract Chrome changes.