clientWidth and offsetWidth equal the box the element itself reports
Check id layout-box-arithmetic
What an ordinary browser yields
A content-box div of width 29px with 17px of left padding and a 3px left border measures clientWidth 46 and offsetWidth 49, exactly.
What a detector infers
clientWidth and offsetWidth are not opinions the browser offers — CSSOM defines them as arithmetic over values the same element hands you through getComputedStyle. Under content-box with no scrollbar, clientWidth is exactly width plus padding, and offsetWidth adds the borders. So a browser can be made to contradict itself using nothing but its own two APIs. The probe is DataDome's own, read opcode by opcode out of its bytecode VM: it creates a div, sets box-sizing to content-box, width to 29px and padding-left to 17px, appends it, reads one value — clientWidth — and removes it. 29 + 17 = 46 is the only answer that closes. We add a 3px border so offsetWidth must independently be 49, which costs nothing and doubles the arithmetic. Two details are worth knowing. DataDome parks its probe at left:-9999px; we park it at left:0 instead, because Blink snaps clientWidth against the box's own x position and at browser page zoom — which getComputedStyle cannot see — a fractional x can legitimately snap the answer to 45 or 47. And their choice of visibility:hidden over display:none is deliberate and correct: a display:none element generates no layout box at all and measures 0, telling you nothing. What this catches is tooling that stubs element metrics to blunt font- and element-size fingerprinting: it patches the getters, not the layout engine, and the sum stops closing. It is also the cheapest possible proof that layout actually ran.
How to resolve it
Leave element metrics native. clientWidth and offsetWidth are computed from the box the layout engine actually built, so overriding them leaves them disagreeing with the computed style of the very same element — a contradiction visible from inside the page with no baseline at all. If different font metrics are the goal, change the fonts rather than the rulers.
Read in the wild by
DataDome
Builds this exact probe box in its bytecode VM — a content-box div at width 29px with 17px of left padding, visibility:hidden rather than display:none (which would generate no box at all) — appends it, reads ONE value, and removes it. 29 + 17 = 46 is the only answer that closes. The constants here are theirs.
out.txt 19719-19803 (addr 0x14121-0x142f4): style.boxSizing="content-box", style.width="29px", style.paddingLeft="17px", style.visibility="hidden", appendChild, GET clientWidth -> reg578, removeChild
xKiian/datadome-vm — DataDome bytecode VM disassemblyEvery attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Render & GPU
- 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… - main-thread metrics === Worker metrics
worker-vs-mainThe same five strings are measured at 12px Arial twice: once on a main-thread 2D canvas, and once inside a dedicated Worker on an… - 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… - 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… - IntersectionObserver's rect agrees with getBoundingClientRect
client-rect-vs-observerA third account of where one element sits, from the most ordinary API that has one. - WebGPU's build constants are identical in every realm
webgpu-sync-surface-vs-realmWebGPU's cheapest fingerprint is not the GPU at all. navigator.gpu.getPreferredCanvasFormat() and navigator.gpu.wgslLanguageFeatures are…
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 layout-box-arithmetic belongs to.