Sec-CH-UA-Arch

Sec-CH-UA-Arch reports the CPU instruction-set family the browser was built for. Typical values are "x86" and "arm". This is the architecture, not the word size, which lives separately in Sec-CH-UA-Bitness.

Accept-CH: Sec-CH-UA-Arch          # server response, once

Sec-CH-UA-Arch: "arm"              # subsequent requests

Why it exists

Almost entirely for one use case the old User-Agent string handled badly: native binary downloads. An Apple-silicon Mac and an Intel Mac present nearly identical UA strings, but "arm" vs "x86" picks the right installer on the server, with no JavaScript sniffing:

Sec-CH-UA-Platform: "macOS"
Sec-CH-UA-Arch: "arm"
Sec-CH-UA-Bitness: "64"
→ serve MyApp-apple-silicon.dmg

The emulation caveat

The value describes the browser build, not the silicon. Chrome running under Rosetta 2 on an M-series Mac reports "x86", because that is what the binary believes it is. Windows-on-ARM running an x86 Chrome does the same (see Sec-CH-UA-WoW64 for the Windows twist). For download pages this is usually the answer you want: an x86 browser can run an x86 app.

In JavaScript

const { architecture } = await navigator.userAgentData
  .getHighEntropyValues(['architecture']);
// "x86" | "arm"

Despite the “high entropy” label, the promise resolves without any user prompt today; the API shape simply leaves room for browsers to gate it later.

Privacy note

Architecture adds real fingerprinting bits (Apple-silicon vs Intel splits macOS users roughly in half), which is why it sits behind Accept-CH rather than flowing by default. Request it on the download page, not sitewide.