screen has an OS chrome inset (avail < screen on either axis)
Check id taskbar-present
What an ordinary browser yields
avail dimensions are smaller than the full screen on at least one axis, reflecting a reserved taskbar or dock — though equality is legitimate in several ordinary setups.
What a detector infers
screen.availWidth/availHeight describe the area left over after the OS reserves space for its own chrome — a Windows taskbar, a macOS dock and menu bar. The check computes the width inset and, if that is zero, falls back to the height inset, and reports whether any inset exists at all. On a typical desktop session, at least one edge is reserved, so avail is strictly smaller than screen on that axis. When the two are identical, a detector learns the environment has no OS shell reserving screen space, which is common in headless and off-screen rendering. The inference is weak on its own, which is why this check is info severity and not scored: fullscreen sessions, auto-hiding taskbars, and some Linux window managers legitimately produce screen === avail. It is context to read alongside the other geometry checks, not a verdict.
How to resolve it
Not directly fixable, and not scored. If the surrounding geometry signals are coherent, screen === avail is unremarkable. Running headful against a real desktop session naturally produces an inset; a bare virtual display will not, and that is expected rather than wrong.
Read in the wild by
Kasada
Its ips.js fingerprint payload collects the available screen area alongside the full screen area, in both the top-level window and its iframe — both terms this check compares ship in the same report.
probes.txt (427-probe map): window_screen_avail_width, window_screen_avail_height (lines 407-408) and iframe_screen_avail_width, iframe_screen_avail_height (lines 189-190) alongside window_screen_width / window_screen_height (lines 413, 410). blog.txt batch 2 slot 132: "window_screen_avail_height(fn_38762)"; batch 8 slot 1: "iframe_screen_avail_width(fn_14771)"; batch 17 slot 32: "window_screen_width(fn_179835)". Decompiled probe fn_46593 (blog.txt:860-861) reads both terms directly: "v1224 = v1224 * charCodeHash(v1222.screen.availWidth, 5); v1224 = v1224 + charCodeHash(v1222.screen.availHeight, 3); ... v1224 = v1224 + charCodeHash(v1222.screen.width, 4);" where v1222 is the iframe reference — blog.txt:882 confirms these are read "from both the window and iframe references".
PerimeterX / HUMAN
PerimeterX's deployed collector reads screen.width, height, availWidth and availHeight in a single function and ships all four as separate fields — six live iFood captures from a Windows host carry 1440/900/1440/852 — so both insets this check computes are derivable from one payload, though the collector only transmits the raw numbers and does not compute the inset itself.
/root/re/PerimeterX_RE/stample/ifood/source/main.min.js — SHA-256 e042d5de834333985610691dbd6e435ca61a744e6a17271e4bbb4c21706a754e, verified-identical snapshot of https://client.px-cloud.net/PXO1GDTa7Q/main.min.js (per stample/ifood/source/SDK_INFO_EN.md). Function Cm(t): `var n=screen&&screen[hQ(692)]||-1,e=screen&&screen.height||-1,r=screen&&screen[hQ(782)]||-1,h=screen&&screen[hQ(783)]||-1;t["Hw9qBVlibDQ="]=n,t["QlJ3GAQwfSs="]=e,t["JDBROmFUUQk="]=r,t["MDxFNnVYRQw="]=h,t[hQ(784)]=n+"X"+e` — where bug_report/sdk_drift_cases/2026-05-19_ifood/hQ_map.json resolves hQ(692)='width', hQ(782)='availWidth', hQ(783)='availHeight'. All six captured payloads (stample/ifood/sample/{1..6}/decoded_payload_2.json; live collector app PXO1GDTa7Q on ifood.com.br, HTTP 200, host UA "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/148.0.0.0") carry "Hw9qBVlibDQ=":1440, "QlJ3GAQwfSs=":900, "JDBROmFUUQk=":1440, "MDxFNnVYRQw=":852. Note: Cm(t) contains no height-minus-availHeight computation.
CreepJS
CreepJS, an open-source fingerprinting research demo rather than a production detector, compares screen.width/height against availWidth/availHeight and counts the absence of any inset (`noTaskbar`) as one of the 16 indicators averaged into its "like headless" rating, while a second copy of the same comparison in its screen module is used only to mark the screen as low-entropy.
abrahamjuliot/creepjs@master, src/headless/index.ts:78-81 — `noTaskbar: (screen.height === screen.availHeight && screen.width === screen.availWidth),` — one of 16 keys in the `likeHeadless` object (lines 31-94), consumed at line 162 (`const likeHeadlessKeys = Object.keys(likeHeadless)`) and line 166 (`const likeHeadlessRating = +((likeHeadlessKeys.filter((key) => likeHeadless[key]).length / likeHeadlessKeys.length) * 100).toFixed(0)`). Separately, src/screen/index.ts:56-59 — `const noTaskbar = !(width - availWidth || height - availHeight)` / `if (width > 800 && noTaskbar) { LowerEntropy.SCREEN = true }` — the same comparison used to discount screen entropy rather than to score headlessness.
Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Screen & display
- devicePixelRatio matches matchMedia resolution
dpr-matchmediaThe check compares window.devicePixelRatio against the layout engine's own answer, querying matchMedia with a min-resolution/max-resolution… - screen dimensions are a plausible physical size
screen-plausibleA pure sanity range on screen.width and screen.height: both must be at least 200px and no more than 16384px. - the available screen area fits inside the screen
screen-avail-within-boundsThe available screen area is a subset of the screen by definition: availWidth and availHeight describe what is left of width and height… - screen.colorDepth decomposes into the CSS color media feature
color-depth-vs-media-colorscreen.colorDepth and the CSS color media feature describe one display in two different units: total bits per pixel, and bits per colour… - the outer window fits within the screen
window-boundsThe check asserts only the zoom-invariant bound: window.outerWidth/outerHeight must be non-zero and must fit within the screen. - a non-touch desktop has a fine pointer + hover
pointer-hover-desktopThis check applies only when the UA identifies a desktop platform (Windows, Macintosh, Mac OS X, X11, Linux, CrOS, and not Android/Mobile)… - maxTouchPoints coheres with pointer media
touch-pointer-coherenceA one-directional coherence test: if navigator.maxTouchPoints is greater than zero, matchMedia("(any-pointer: coarse)") is expected to… - screen dimensions resolve via native prototype getters
screen-descriptorsFor width, height, availWidth, availHeight, colorDepth and pixelDepth this asks two questions: does the screen instance carry an own…
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 Screen & display 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 Screen & display — the family taskbar-present belongs to.