Sec-CH-Viewport-Width

Sec-CH-Viewport-Width carries the width of the layout viewport, in CSS pixels, on the request itself: media-query input, delivered before a single byte of your response is written.

Accept-CH: Sec-CH-Viewport-Width

Sec-CH-Viewport-Width: 1920    # desktop window
Sec-CH-Viewport-Width: 390     # an iPhone-class phone

CSS pixels, not physical ones; multiply by Sec-CH-DPR to get device pixels.

Server-side responsive decisions

Media queries decide after CSS arrives; this header lets the server decide first:

• Image sizing: an image CDN can compute “full-bleed hero on a 390px viewport at DPR 2 → serve 780px wide” with no srcset in the markup.
• Payload pruning: skip shipping the mega-menu markup and desktop data tables to a 390px viewport at all, rather than hiding them with CSS.
• Above-the-fold budgets: inline exactly the critical CSS that a viewport this size will render.

Caveats worth knowing

• It’s the viewport at request time. The user can resize the window or rotate the phone afterward; client-side responsiveness stays necessary. The header optimizes the initial payload, it does not replace media queries.
• First-visit gap. Like every opt-in hint, it’s absent on the very first request unless you use Critical-CH (see Accept-CH).
• Cache carefully. A response that varies by viewport width can explode cache cardinality. Vary: Sec-CH-Viewport-Width is correct but effectively per-window-size; most CDNs bucket the value (e.g. into standard breakpoints) before using it as a cache key.

In JavaScript

window.innerWidth  // layout viewport width in CSS px

Legacy note: shipped 2015 as bare Viewport-Width alongside DPR and Width; both spellings work in Chromium, new configs should use the Sec-CH- form.