No cache-validation headers on requests that should carry none
Nothing. A default-mode fetch and a fresh navigation both arrive with no Cache-Control, no Pragma and no conditional headers.
What a detector infers
A real Chrome sends no cache-validation headers on a request it has not been told to revalidate. This was measured rather than assumed: against our own probe, a plain fetch carried no Cache-Control and no Pragma, while fetch with cache:"no-store" and cache:"reload" both emitted Pragma: no-cache and Cache-Control: no-cache. The absence is the browser's genuine behaviour on a cold navigation, so any presence was authored by something. Automation stacks author it routinely.
A navigation path forced to bypass the cache stamps no-cache and Pragma onto every top-level navigation; a reload stamps max-age=0; a driver rewriting headers through a request interceptor stamps whatever it intercepts. What makes this worth reading is where it lives: the header is written by the network stack, below the runtime, before page script exists.
No override on navigator reaches it, nothing in JavaScript reveals it, and a page cannot even read its own request headers to notice — which is why it survives every check that only reads the JS surface, and why a server has to be asked.
The check uses two arms because they catch different mistakes: a plain fetch catches a driver stamping everything it touches, and an iframe load — a genuine navigation, Sec-Fetch-Mode: navigate, where a fetch is not — catches a stack that stamps navigations specifically.
The iframe is created late, on purpose: Chrome propagates a reload's cache mode to the subresources of that load, so a frame created during load could inherit a hard reload's no-cache and make an honest visitor look driven.
How to resolve it
These headers are attached by the network stack rather than by page script, so nothing in JavaScript put them there and nothing in JavaScript will take them off. They appear when a navigation is forced to bypass the cache, or when a driver rewrites headers through a request interceptor. Fix it where it is written: stop forcing cache-bypass on navigations, and stop adding headers a real cold navigation does not carry.
The honest alternative reading is why this row never scores — a corporate TLS-terminating proxy or a CDN in front of a site can add request headers too, and that is the network's doing rather than the browser's.
Nearby checks in HTTP request vs the runtime
- The image Accept header is the one the claimed Chrome major sends
image-accept-vs-claimed-majorThe Accept header Chrome sends for an <img> is compiled from the image formats the build decodes by default, and it changed at 155: JPEG XL… - A cacheable resource fetched twice comes from cache the second time
http-cache-honouredA browser that is allowed to cache a response does. The probe fetches an immutable, cacheable resource unique to this visit twice, then… - A WebSocket handshake carries the no-cache pair every browser sends
websocket-handshake-no-cacheA WebSocket connection starts as an HTTP request that is never cacheable, and browsers mark it that way. - 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… - Global Privacy Control reads the same in the page, in a worker and on the wire
gpc-header-vs-navigatorGlobal Privacy Control has three faces: navigator.globalPrivacyControl in the window, the same property in workers, and the Sec-GPC: 1… - 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…
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 request-cache-headers belongs to.