Sec-Fetch-* describes the request this page actually made
Check id sec-fetch-metadata
What an ordinary browser yields
Sec-Fetch-Mode: cors and Sec-Fetch-Dest: empty, with Sec-Fetch-Site either same-site or cross-site depending on the probe's domain.
What a detector infers
Sec-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, what kind of fetch it was, and what the result is for. They are explicitly forbidden to page script: fetch() cannot set them, which is the entire design of the header family. So for a request this page just made with fetch(), their values are specified in advance, and the check compares what arrived against what the spec requires: mode=cors, dest=empty. The site value is accepted as either same-site or cross-site, because the probe shares a registrable domain with this page and legitimately reports same-site — a detail worth stating, since asserting cross-site would have been wrong here and was caught only by measuring. Absence is treated as no measurement rather than a finding: these headers ship in every current browser, but an old one lacking them is old, not automated, and this audit does not convict browsers for their age.
How to resolve it
Nothing to fix on an ordinary browser. These headers cannot be set from script by design, so values disagreeing with the request the page actually made mean the request was replayed or synthesised outside the browser's own fetch — which is the situation the header family exists to make visible.
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… - 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. - 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-fetch-metadata belongs to.