Accept-Language leads with the same language as navigator.languages
Check id accept-language-vs-navigator
What an ordinary browser yields
The first language in Accept-Language equals navigator.languages[0]. The header carrying fewer languages than JS reports is normal and not asserted.
What a detector infers
Accept-Language and navigator.languages are two views of one browser preference: the header is serialised by the network stack, the array is read by JS. They must lead with the same language. What the check deliberately does NOT do is compare the full list, and the reason is a measurement rather than a guess. Current Chrome ships Accept-Language reduction — it sends a single language on the wire while still reporting the complete list to JS. Measured on a stock browser during development: the header carried exactly `en-GB` while navigator.languages held ['en-GB', 'en-NL']. A full-list comparison would therefore fail an ordinary, unmodified Chrome, which is the failure mode this audit takes most seriously. Only the primary tag is a fact both layers still agree on, so only the primary tag is asserted. Severity is warn rather than critical because the header's exact serialisation is a moving target — the reduction itself is a recent change, and the surface may narrow further.
How to resolve it
Set the language in the browser rather than overriding navigator.languages: the header is written from the real preference, so a JS-side edit leaves the wire advertising the language you were trying to change.
Other checks in HTTP request vs the runtime
- the client-hint headers match navigator.userAgentData
sec-ch-ua-vs-uadataUser-Agent Client Hints exist in two places at once, which is what makes them checkable. - 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 accept-language-vs-navigator belongs to.