Sec-CH-Width

Sec-CH-Width is the most specialized device hint: it describes not the device, but the resource being requested: the physical width, in device pixels, at which this particular image will be displayed.

GET /img/hero.jpg HTTP/1.1
Sec-CH-DPR: 2
Sec-CH-Width: 780     # this image will render 390 CSS px wide on a 2× screen

The catch: it needs sizes

The browser can only know an image’s display width before fetching it if the markup says so. Sec-CH-Width is therefore only sent on requests for images that carry a sizes attribute:

<img src="/img/hero.jpg" sizes="(max-width: 600px) 100vw, 600px" alt="…">

No sizes, no header. That is the single most common reason people opt in and then see nothing arrive. It also never appears on document or API requests, so our own echo endpoint on this site will show it missing: this page’s fetch is not an image with sizes.

Why it beats srcset

With srcset the client picks from a list you pre-generated. With Sec-CH-Width the server knows the exact target width and can generate or select precisely that rendition: no 320/640/1280 staircase, no over-serving by a breakpoint. This is the protocol image CDNs use to do “automatic responsive images” with a plain <img> tag plus one sizes attribute.

The server should answer with Content-DPR when it serves a scaled rendition, so the browser displays it at the intended CSS size (explained on the Sec-CH-DPR page).

No JavaScript equivalent

Uniquely in this registry, there is no JS API for it; the value only exists per-image-request, computed by the browser’s preload scanner. Legacy spelling Width (2015) still works in Chromium; prefer the Sec-CH- form in new Accept-CH lists.