Sec-CH-Device-Memory

Sec-CH-Device-Memory reports how much RAM the device has, deliberately fuzzed into coarse buckets so it informs performance decisions without becoming a precise fingerprint.

Accept-CH: Sec-CH-Device-Memory

Sec-CH-Device-Memory: 8

The bucket scale

The only possible values are 0.25, 0.5, 1, 2, 4, and 8. Real RAM is rounded down to the nearest bucket, and the scale is capped: a 64 GB workstation and an 8 GB laptop both say 8, a 12 GB phone says 8, a 3 GB budget phone says 2. The cap is intentional: beyond “plenty”, more precision would only serve fingerprinting.

What to do with it

This hint is the server-side half of the “device-class adaptive” pattern:

• 0.25–1 is entry-level. Serve the lite bundle: no heavy frameworks, static images instead of video, aggressive lazy-loading.
• 2–4 is mid-range. Standard experience, maybe skip the optional 3D flourishes.
• 8: don’t over-infer; it means “not memory-constrained”, nothing more.

Companies with large low-end-device audiences (commerce and media in emerging markets, most famously) use exactly this split to decide at the edge which app shell to serve, before any JavaScript runs.

In JavaScript

navigator.deviceMemory  // 8, same bucket scale

Chromium-only in both forms. Like Sec-CH-DPR, it shipped years before the Sec-CH- prefix existed, and Chromium still honors the legacy Device-Memory name when requested in Accept-CH, but new configs should use the prefixed form.

One design warning: never gate functionality on a memory bucket. It’s an optimization signal for payload weight, not a capability test. A 2 device must still get a working site, just a lighter one.