Why 30% of our profiles use dark mode

The share of browsers that report prefers-color-scheme: dark is well below what people say when asked whether they like dark mode, so that is the number we draw from. Each Mosaic profile now claims dark mode 30% of the time. Before September 2026 every profile on our build Mac claimed dark, because the Mac itself was set to dark.

How it was found

The question was small: do profiles randomise dark mode? We drew two profiles with different machines, screens and graphics chips, opened a local page in each, and printed macOS's own settings beside them. Both said dark, and so did the Mac. A value identical in two unrelated profiles and equal to the computer underneath is not a claim the profile makes. The profile has inherited it from the host.

The same page asked for every client hint, and the value was there too, as a request header: Sec-CH-Prefers-Color-Scheme: dark. A site that requests the hint gets it before running any script.

Dark mode was the mildest row of that sweep. The same Mac also had reduced motion and reduced transparency turned on, two accessibility settings a small minority use, and every profile was reporting both. A rare trait shared by every profile on one machine is worse than a common one, because it narrows the group a site has to look at.

How it works: Machines that exist

The prefers-color-scheme dark mode share, not the survey share

The first number that comes to mind is the survey number. Ask people whether they prefer dark mode and a large majority say yes. If we drew profiles from that, most of them would be dark.

A site does not see preferences, though. It sees what the operating system reports, and many people who like dark mode in principle never change the light theme their computer shipped with. The traffic measurements we read before picking a number all put dark well under a third of real visitors. A population of profiles drawn from the survey figure would be unusual in the direction we are trying to avoid: too many dark browsers coming from one place.

So we drew 30%. That is above the traffic figures we found, because use of dark mode has been rising, and far below the survey figures, because surveys are not what sites see. Being exactly right matters less here than being on the right side of the gap.

The other settings, drawn the same way

The accessibility settings got the same treatment, with smaller numbers:

prefers-color-scheme: dark        30%
prefers-reduced-motion: reduce     4%
prefers-reduced-transparency       2%
prefers-contrast: more             2%

For these the exact figure matters less than two properties: small, and not zero. Zero would be a population with no one using accessibility settings, which is not a real population either. What we were escaping was 100%, which is what inheriting a host with those settings on gives you.

Drawn from the seed, so old profiles agree with themselves

We had 344 profiles on that machine when this changed, and a new rule in the generator reaches only profiles drawn after it. So the preferences are not stored at creation. They are computed from each profile's seed the first time they are read. An old profile gets a value without its file being rewritten, and it gets the same value at every launch, because the seed does not change.

Repairing a profile's hardware does not redraw them. A repair moves the machine a profile claims, its graphics chip, screen and thread count. Dark mode is a choice a person makes about that machine, so it stays.

The general rule

Draw from what browsers send, not from what people say. A survey measures opinion; a fingerprint is made of settings. The values that mattered in this sweep were ones nobody thinks of as identifying, and they were identifying because they were the same everywhere. The day before this post, we wrote up the same fault with a value we had pinned ourselves: 344 profiles reporting notification permission as denied.

How the colour scheme fits with the rest of a drawn machine is on real fingerprints, and the full list of values a page can read is in browser fingerprint. Locale had a fault of the same family: a profile in Austria that claimed New York.