The image Accept header is the one the claimed Chrome major sends
Under the Google Chrome brand, a claim of 155 or later sends image/jxl in its image Accept header and an earlier claim does not. N/A for other brands and engines (severity: warn).
What a detector infers
The 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 decoding was switched on by default, so the header now begins image/jxl,image/avif,image/webp where 154 began with image/avif. That makes the header a version stamp written by the network stack, below any user-agent override, in the same way the TLS ClientHello is for tls-extensions-vs-claimed-major.
A browser claiming Chrome 155 or later without image/jxl has an older engine than it says; one claiming an earlier major with it has a newer one. Measured: Chrome 155 on Windows and Linux and Edge 155 send image/jxl; Playwright's Chromium 149 under a Chrome/155 user agent does not, and neither does chrome-headless-shell 153.
The exceptions are stated rather than hidden: an enterprise policy, a field-trial kill switch or --disable-features=JXLImageFormat removes it, and the DevTools protocol's setDisabledImageTypes edits the header, so flags and policies can move it in either direction. macOS has not been measured yet. The row holds the Google Chrome brand to Chrome's own history; other brands and engines keep their own image lists and are N/A.
How to resolve it
Claim the Chrome major the binary actually is. The Accept header is written by the network stack from the formats the build decodes, so a user-agent override changes the version and leaves the header describing the real one.
Nearby checks in HTTP request vs the runtime
- Client hints on the wire carry the values JavaScript reports
client-hints-wire-vs-jsA server that asks for client hints with Accept-CH receives, on the next request, headers that describe facts JavaScript can also read… - 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 image-accept-vs-claimed-major belongs to.