Downlink

Downlink carries the browser’s estimate of downstream bandwidth, in megabits per second:

Accept-CH: Downlink

Downlink: 10
Downlink: 1.4

Read the cap before anything else

The value is clamped to 10 Mbps. Gigabit fiber, 5G, and office ethernet all report 10. Like the 8 bucket in Sec-CH-Device-Memory, the cap exists because beyond “enough for rich media” extra precision would only feed fingerprinting. So Downlink cannot rank fast connections; it can only flag slow ones. 10 means “not bandwidth-constrained”, 1.4 means “every megabyte hurts”.

It is also an estimate from recent transfer behavior (rounded to 25 kbps steps), so treat small differences as noise.

Sensible uses

• Media selection: a video platform picking the starting rendition ladder rung server-side. Below ~2 Mbps, start at 480p and let ABR climb.
• Preload budgets: skip speculative prefetching entirely under ~1.5 Mbps; the bandwidth belongs to what the user actually requested.
• Telemetry: bandwidth distribution by market when planning payload budgets.

For serving decisions with caching involved, prefer ECT, which gives you four values instead of a numeric continuum, and honor Save-Data as an absolute override: a user on fast Wi-Fi with data saver on still asked for the light version.

In JavaScript

navigator.connection?.downlink   // 10, in Mbps
navigator.connection?.addEventListener('change', reassess);

Chromium-only like the rest of the Network Information family, experimental per MDN, unsupported in Firefox and Safari. Absence of the header must mean “assume fast”. Punishing browsers that stay quiet is the one universally wrong move.