C:/ parses the way the claimed OS's Chromium parses it
The URL constructor, an anchor's href and a Request agree on 'C:/x'; under a Chromium desktop claim the answer is 'file:' for Windows and 'c:' otherwise. Other engines and mobile claims are held only to the agreement (severity: warn).
What a detector infers
Chromium'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 canonicalised to file:///C:/x. The rule is compiled in only on Windows builds (url_util.cc, under WIN32). On macOS and Linux the same string is a URL with the scheme 'c', so new URL('C:/x').protocol is 'c:'.
The three ways a page can parse a URL — the URL constructor, an anchor's href and a Request's url — all go through that one code path, so they agree with each other and with the operating system the binary was built for. Measured: 'file:' on all three in Chrome and Edge on Windows and 'c:' on all three on genuine Linux Chrome, while Linux Chrome claiming Windows gives 'c:' and Windows Chrome claiming Linux gives 'file:'.
Gecko and WebKit return 'c:' everywhere, so the OS comparison applies to Chromium desktop claims only; every engine is still expected to give one answer on all three entry points. url-parser-spec-conformance once included this probe and rightly dropped it: as a question about the specification it has no single right answer, but as a question about which OS the binary was built for, it does.
How to resolve it
Present the OS the browser was built for. The drive-letter rule is compiled into the URL library, so no user-agent or platform override reaches it, and patching the URL constructor in script leaves the anchor and Request paths giving the real answer.
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. - 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. - Device-level media features are identical in a fresh realm
media-surface-vs-realmMedia features are answered by the layout engine rather than by the JavaScript properties that describe the same machine, which is what…
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 url-drive-letter-vs-os belongs to.