Under a Windows claim, ActiveText is the Windows hotlight colour, not Chrome's red
Under a Windows claim, from Chrome 138: ActiveText in the light scheme is not rgb(255, 0, 0). N/A for other claimed OSes, earlier majors and forced colours (severity: warn).
What a detector infers
ActiveText is a CSS system colour for links being activated. Since Chrome 138, Chrome on Linux and macOS resolves it from its built-in palette to pure red, rgb(255, 0, 0), while Chrome on Windows takes the system hotlight colour, rgb(0, 102, 204) unless the user changed it. A user agent and navigator.platform can claim Windows, but the colour comes from the platform code Chrome was built for, so a Linux machine presenting itself as Windows shows red.
The audit reads ActiveText in the light scheme and skips forced-colours mode, where the palette is the user's. Measured on 2 November 2026 on Windows: genuine Chrome 156 and Clearcote give rgb(0, 102, 204). A Windows theme with a red hotlight colour would fail this row, which is why it is a warning.
How to resolve it
Claim the OS the browser runs on, or run it on the OS it claims: the colour comes from Chrome's platform code, not from anything a page or a user-agent setting reaches.
Nearby checks in Capability surfaces
- Web Share is present or absent as the claimed platform's Chrome ships it
web-share-vs-osnavigator.share is present or absent depending on the platform the Chrome binary was built for. - C:/ parses the way the claimed OS's Chromium parses it
url-drive-letter-vs-osChromium's URL library contains a Windows-only rule: a string that begins with a drive letter, such as 'C:/x', is treated as a file path and… - The system colour palette belongs to the claimed OS
system-colors-vs-osWindows and Linux Chrome resolve the CSS system colours and their built-in form-control styles differently, and some of the differences are… - hrefTranslate is present under the Google Chrome brand
href-translate-vs-brandHTMLAnchorElement.prototype.hrefTranslate is a runtime-enabled feature that Chrome only switches on when its translation service is… - The device-API family is present or absent as a unit
device-api-family-coherenceWeb Bluetooth, WebUSB, WebSerial and WebHID are one family on Chromium desktop - the same secure-context gating, the same desktop platforms… - A build claiming Chrome carries the Privacy Sandbox surface Chrome ships
privacy-sandbox-vs-chrome-claimTopics, Protected Audience, Shared Storage and Fenced Frames all shipped to Chrome stable in 115 and are present by default on desktop. - Firefox resistFingerprinting announces itself when enabled
firefox-resist-fingerprinting-identifiableFirefox's privacy.resistFingerprinting substitutes CONSTANTS rather than randomness, and a constant is itself a fingerprint. - The CSS feature surface is identical in a fresh realm
css-surface-vs-realmWhich CSS properties, values and selectors an engine understands is decided when the browser is compiled.
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 Capability surfaces 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 Capability surfaces — the family activetext-vs-windows belongs to.