the order your browser emits its HTTP headers in
Check id http-header-order-readout
What an ordinary browser yields
Contextual only. There is no correct answer to compare against — the order is shown so you can see what a server learns from a request before it reads a single value.
What a detector infers
A browser emits its request headers in a fixed sequence compiled into its network stack, and that sequence differs between engines — Chromium, Gecko and WebKit each have their own, and an HTTP library has one that resembles none of them. It is genuinely a signal, and it is one JavaScript cannot see or change: by the time page script runs, the order was decided by code far below it. This row is nevertheless REPORTED and never scored, and the reason is a rule this audit learned the hard way. Naming a browser from its header order requires a table of known orders, and tables rot: this page already shipped one — a set of V8 heap-size values — which went stale and began telling people with a stock Chrome that their browser was implausible. A header-order table would rot faster and fail louder. Every scored check here compares the browser against itself, so it can only ever go quiet when it meets something unfamiliar; a lookup table goes wrong instead. So the order is shown, with an explanation of what it reveals, and no verdict is attached to it.
How to resolve it
Nothing to fix. If you are presenting an identity that the header order contradicts, note that the order comes from the network stack rather than from anything a page or an extension sets — matching it means using the engine you claim, not editing a value.
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. - 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… - 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 http-header-order-readout belongs to.