main-thread metrics === Worker metrics
Check id worker-vs-main
What an ordinary browser yields
All five widths identical between the main thread and the Worker.
What a detector infers
The same five strings are measured at 12px Arial twice: once on a main-thread 2D canvas, and once inside a dedicated Worker on an OffscreenCanvas, compared to a tolerance of 1e-9. Text shaping runs the same engine code in both scopes, so a real browser returns bit-identical widths. Modifications applied only to the page's CanvasRenderingContext2D — the common case, since that is the realm injected scripts land in — never reach the Worker, so the two sets diverge. A detector reads that divergence as proof of scope-limited modification rather than of any particular hardware: the two answers cannot both be what the engine natively computes. N/A if the Worker fails to construct or does not answer within 5s.
How to resolve it
Apply any canvas or text-metric modification at a level both scopes share (engine-level), or apply none at all. Patching only the document's canvas prototype guarantees this divergence, and adding a second patch inside Workers only moves the problem to the next realm a detector opens.
Nearby checks in Render & GPU
- canvas measureText widths on the 1/512 sub-pixel grid
measuretext-gridChrome's 2D text metrics are quantised: advance widths are computed in fixed-point and land on a dyadic 1/512-pixel grid. - text metrics are not a uniform multiple of the engine's own grid
text-metrics-uniform-scaleThis is the sub-pixel grid check asked one question deeper. That check reports THAT widths have left Blink's 1/512-pixel grid; this one asks… - N copies of a glyph measure exactly N times one copy
text-advance-additivityThe advance width of N copies of a single glyph is exactly N times the advance of one copy. - ink extent and advance width grow by the same step
text-ink-extent-vs-advanceTextMetrics reports two numbers produced by different parts of the engine. width is the sum of the glyph advances the shaper accumulated… - getBoundingClientRect === Range client rects
bcr-vs-rangeTwo independent APIs are pointed at the same laid-out text: an absolutely-positioned div containing "WWWWWiiiii" is measured with… - clientWidth and offsetWidth equal the box the element itself reports
layout-box-arithmeticclientWidth and offsetWidth are not opinions the browser offers — CSSOM defines them as arithmetic over values the same element hands you… - a box placed at the viewport origin measures its origin as zero
client-rect-origin-vs-positionZero is scale-invariant, and that single property is the whole check. - SVG's screen matrix agrees with the element's client rect
svg-ctm-vs-client-rectTwo independent routes to a single fact. getScreenCTM maps an SVG element's user space into viewport coordinates, and getBoundingClientRect…
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 Render & GPU 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 Render & GPU — the family worker-vs-main belongs to.