Accept-CH general response

What it does

Accept-CH requests that the browser include specific Client Hints on subsequent requests to this origin — structured, opt-in alternatives to parsing the notoriously messy User-Agent string for device and preference information. Instead of guessing device characteristics from a User-Agent string (a long-standing web development pain point, given how inconsistent and spoofable UA strings are), a server can explicitly ask for exactly the hints it needs — viewport width, device pixel ratio, preferred color scheme, platform — and the browser includes them as dedicated, structured request headers going forward.

This is part of a broader effort (Client Hints, alongside User-Agent-Client-Hints) to move the web away from User-Agent string sniffing toward a more deliberate, privacy-conscious, opt-in model for device/preference detection.

Syntax

Accept-CH: <hint1>, <hint2>

Example:

Accept-CH: Sec-CH-UA, Sec-CH-UA-Platform, Sec-CH-UA-Mobile, Viewport-Width, DPR

Once a browser receives this, it includes the requested hints on subsequent requests to that origin — the first request typically doesn't have them yet, since the browser needs to be told what to send before it starts sending it.

Common Client Hints requested

How it's used in practice

• Responsive image serving without client-side JavaScript — a server can use DPR and Viewport-Width hints to select an appropriately-sized image variant server-side, rather than relying purely on <picture>/srcset client-side logic or JavaScript-based detection.
• Reduced-data-mode adaptation — checking Save-Data lets a server serve lighter payloads (lower-resolution images, fewer non-critical resources) for users who've explicitly requested data savings, respecting their preference server-side rather than only client-side.
• Structured browser/platform detection replacing User-Agent parsing — instead of maintaining regex patterns to parse increasingly "frozen"/generic modern User-Agent strings, servers requesting Sec-CH-UA/Sec-CH-UA-Platform get clean, structured, purpose-built values.
• Dark mode content adaptation — Sec-CH-Prefers-Color-Scheme lets a server render dark-mode-appropriate content server-side (useful for server-rendered apps, or email/AMP-style contexts where client-side media queries alone aren't sufficient).

Common mistakes and gotchas

Expecting hints on the very first request. Since the browser needs to first learn (via Accept-CH) which hints a server wants, the first request to an origin generally won't include the requested hints yet — only subsequent requests will, once the browser has processed the header. Designing logic that assumes hints are present from request one will break for first-time visitors.

Not setting Vary correctly when content varies by client hint. If your response content genuinely differs based on a client hint value (serving different images based on DPR, for example), you need to include that hint in your Vary header (or the newer Critical-CH mechanism for hints needed before the first response) — otherwise caches (including CDNs and browser cache) may serve the wrong variant to different clients.

Requesting far more hints than actually needed. Each requested hint adds a small amount to every subsequent request's header size, and from a privacy perspective, requesting hints you don't actually use is both unnecessary overhead and a weaker privacy posture than necessary — only request what your server logic genuinely acts on.

Assuming universal browser support. Client Hints support varies across browsers — Chromium-based browsers have led adoption, while others have been slower or more conservative (partly for privacy reasons, since exposing granular device/preference data has fingerprinting implications browser vendors weigh carefully). Design fallback behavior for browsers that don't send requested hints at all.

Real-world examples

Server requesting device and platform hints:

HTTP/1.1 200 OK
Accept-CH: Sec-CH-UA-Platform, Sec-CH-UA-Mobile, DPR, Viewport-Width

Subsequent request including the requested hints:

GET /page HTTP/1.1
Sec-CH-UA-Platform: "macOS"
Sec-CH-UA-Mobile: ?0
DPR: 2
Viewport-Width: 1440

Correctly varying cached responses by a client hint:

HTTP/1.1 200 OK
Accept-CH: DPR
Vary: DPR
Content-Type: image/webp

FAQ

Why don't I see the requested hints on the first request?

The browser needs to first receive Accept-CH before it knows to start sending those hints — the very first request to an origin won't include them yet. This is a fundamental part of how the opt-in mechanism works, not a bug.

Do Client Hints replace User-Agent entirely?

Not entirely, but they're part of a deliberate move away from relying on User-Agent string parsing for detailed device/browser information — modern browsers have also progressively "frozen" or genericized their User-Agent strings specifically to push adoption toward the more structured, purpose-built Client Hints approach.

Are Client Hints a privacy concern?

They're designed with privacy considerations in mind — unlike a raw User-Agent string (which can leak a lot of passive fingerprinting-relevant detail by default), Client Hints are opt-in per-hint, meaning a server only receives what it explicitly requests, giving more deliberate control over exactly what device/preference information gets exposed.

What happens if I forget to set Vary when content depends on a Client Hint?

Caches (browser cache, CDNs, intermediate proxies) may serve a cached response generated for one hint value to a client with a different value — for example, serving a high-DPR-optimized image to a low-DPR device or vice versa, defeating the purpose of requesting the hint in the first place.

Fun fact

Client Hints' design — requiring an explicit opt-in request via Accept-CH before any hints are sent — is a deliberate architectural choice to avoid recreating User-Agent's biggest problem: passive, always-on information leakage to every server a browser talks to, whether that server needs it or not. By making detailed device/preference information opt-in and per-hint rather than bundled into every single request by default, Client Hints represent one of the more privacy-conscious redesigns of a long-standing, genuinely messy piece of web platform legacy.