the client-hint headers match navigator.userAgentData
Check id sec-ch-ua-vs-uadata
What an ordinary browser yields
sec-ch-ua's brand set, sec-ch-ua-mobile and sec-ch-ua-platform match navigator.userAgentData's brands, mobile and platform exactly.
What a detector infers
User-Agent Client Hints exist in two places at once, which is what makes them checkable. The browser serialises its brand list into the sec-ch-ua, sec-ch-ua-mobile and sec-ch-ua-platform request headers, and exposes the same list to script as navigator.userAgentData. One internal source, two renderings — so they must agree, and patching userAgentData in the page world leaves the headers announcing the truth. These three are also the only hints sent cross-origin without explicit delegation, which is precisely why they are the three compared. Two details keep the check honest. Brands are compared as a SET rather than a sequence, because the specification deliberately shuffles brand order (and injects a GREASE brand like 'Not/A)Brand') to stop anyone depending on the arrangement — asserting order would fail real browsers by design. And the whole check declines on engines that have no client hints at all, since Gecko and WebKit ship neither the headers nor the API, and their absence is a fact about the engine rather than a contradiction.
How to resolve it
The hints are written onto the wire from the same brand list the API reads. Overriding navigator.userAgentData in the page leaves the headers unchanged, so the browser ends up announcing two identities on one request. If the brand list must differ, it has to be changed below JavaScript.
Other checks in HTTP request vs the runtime
- Accept-Language leads with the same language as navigator.languages
accept-language-vs-navigatorAccept-Language and navigator.languages are two views of one browser preference: the header is serialised by the network stack, the array is… - Sec-Fetch-* describes the request this page actually made
sec-fetch-metadataSec-Fetch-Site, Sec-Fetch-Mode and Sec-Fetch-Dest are attached by the browser to describe the request's own provenance — where it came from… - the order your browser emits its HTTP headers in
http-header-order-readoutA browser emits its request headers in a fixed sequence compiled into its network stack, and that sequence differs between engines… - no cache-validation headers on requests that should carry none
request-cache-headersA real Chrome sends no cache-validation headers on a request it has not been told to revalidate.
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 HTTP request vs the runtime 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 HTTP request vs the runtime — the family sec-ch-ua-vs-uadata belongs to.