text layout uses the font scaler of the operating system claimed
The share of 0.01 px size steps that change the text width matches the claimed OS: nearly all of them on Windows and macOS, about two in three on Linux, Android and ChromeOS.
What a detector infers
Every operating system draws text with its own font scaler: DirectWrite on Windows, Core Text on macOS, FreeType on Linux, Android and ChromeOS. Blink first snaps a font size to hundredths of a pixel, then hands it to that scaler, and the two families of scaler treat those hundredths differently. DirectWrite keeps them, so stepping a font size up by 0.01 px changes the width of a line of text almost every time.
FreeType works in 1/64-pixel fixed point, so neighbouring hundredths often collapse onto the same internal size and about a third of the steps change nothing. The audit steps a 54-character string through 200 such sizes and counts the steps that change its width. Measured on 2026-09-24: Chrome on Windows 11 changed on 99% of steps, a Linux browser on 66%, and the same Linux browser presenting a Windows user agent on 66%.
The figure was identical for sans-serif, serif and monospace, and in canvas measureText and page layout alike, which is how a property of the scaler rather than of a font looks. No reference widths are involved: the browser's widths are only compared with themselves, so the fonts installed and the browser version do not matter. The scaler is picked by the host OS below Blink, so navigator.platform, the user agent and the font list never reach it.
How to resolve it
Run the browser on the operating system it claims, or claim the one it runs on; the scaler cannot be selected from inside the browser. Clearcote's Linux build claims Linux by default for this reason, and its hosted browsers run on Windows machines. The row declines at a device pixel ratio above 1 when it reads the Windows pattern, because a HiDPI Linux screen produces that pattern too (measured: 99% at 2x), so it never accuses a real Linux user of running Windows.
Read in the wild by
Scrapfly
Published the underlying observation: one text measurement at a fractional font size separates FreeType from DirectWrite and Core Text, and a Linux build presenting Windows still measures at the FreeType value. Their model is that FreeType floors the size to 1/64 px; our measurement agrees on the effect but finds slightly more change than a strict 1/64 grid allows, so this row scores the measured rate instead of the model.
textWidth(24.5555) on Chrome 150: Windows and macOS 458.16650390625, Linux 458.108642578125.
scrapfly.dev: What getClientRects reveals about FreeTypeClearcote (measured)
Clearcote 149 in its Linux Docker image, with CC_PLATFORM=windows, presents a Windows user agent and navigator.platform "Win32" but changes text width on 476 of 720 hundredth steps, the Linux figure. With the default Linux persona the same reading is coherent and this row passes. Recorded as a known gap for a Windows persona on a Linux host.
720 consecutive hundredths from 20 to 27.2 px, sans-serif/serif/monospace, canvas and getBoundingClientRect: Windows Chrome 714/720, Clearcote Linux (either persona) 476/720.
Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Engine & OS oracles
- the CPU architecture matches the architecture the browser claims
cpu-arch-nan-vs-uachIEEE-754 fixes the exponent and the quiet bit of a NaN but leaves the sign bit to the hardware, and the hardware disagrees: an x86 FPU… - JavaScript and WebAssembly read the same CPU
cpu-arch-nan-wasm-vs-jsIEEE-754 leaves the sign bit and payload of a quiet NaN to the implementation, and the two dominant architectures chose differently: x86… - the three heap numbers describe a possible heap
jsheap-triplet-orderingThis check replaces a retired one, and the swap is the lesson. - the platform's system font belongs to the operating system claimed
system-font-vs-claimed-osThe CSS2 system-font keywords — caption, icon, menu, message-box, small-caption and status-bar — are resolved by the HOST platform's font… - core Windows fonts that measure as installed also load by name
windows-fonts-load-by-nameA page can ask whether a font is installed in two ways. It can measure: draw a string in the font with a generic fallback and see whether… - a Windows face that loads by name is also visible to text layout
font-loads-by-name-vs-layoutThis is the row above asked in the other direction. A page can learn whether a font is installed by loading it by name, new FontFace(x… - a Windows CJK font answers to its localized family name as well as its English one
font-localized-alias-vs-englishWindows fonts carry their family name in more than one language. - typefaces the claimed OS ships as separate faces measure as separate faces
claimed-os-typefaces-are-distinctA font request is answered by the host's font stack, not by the browser and not by anything the user agent sets, so changing…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Engine & OS oracles checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Engine & OS oracles — the family text-scaler-vs-claimed-os belongs to.