Chrome's User-Agent Reduction program froze the UA string's minor version, OS detail, and device model. Here's exactly what changed, why, and what replaced it.
If your Chrome User-Agent string reports Chrome/143.0.0.0 while chrome://version tells you the build you're actually running is something like 143.0.7499.96, you're not misreading either one — Chrome really did stop reporting its exact version. That's not a bug. It's the deliberate outcome of Chrome's User-Agent Reduction program: a multi-year effort to strip the passively-broadcast UA string down to a low-detail stub, moving the specifics into an opt-in API instead. Here's exactly what got removed, what it was replaced with, and what the frozen values mean for spoofing detection.
Key Takeaways
- Chrome's User-Agent Reduction removed three things from the UA string: the minor/build/patch version, the exact OS version, and the device model.
- Everything after the major version now always reads
0.0.0— any Chrome 143 build reportsChrome/143.0.0.0, whichever patch release it really is. Desktop OS strings are frozen to fixed values likeWindows NT 10.0for every Windows release since 10. - Android device models are replaced with the generic placeholder
K, and the reported Android version is frozen at10, regardless of the real device or OS build. - The removed detail didn't disappear — it moved to User-Agent Client Hints (UA-CH), which discloses it only when a server explicitly requests it.
- Because the frozen UA no longer moves with real updates, a User-Agent that disagrees with the browser's actual feature-detected engine version becomes a stronger spoofing signal, not a weaker one.
What actually got removed
Chrome's reduction targets exactly three fields, according to MDN's User-Agent reduction reference:
- The exact platform/OS version — no longer your real Windows build, macOS point release, or Android version.
- The device model — Android phone/tablet model strings are gone.
- The minor browser version — only the major Chrome version remains meaningful; everything after it is zeroed.
The replacement values are fixed, not approximated — every device on a given platform reports the identical string:
| Platform | Frozen value |
|---|---|
| Windows | Windows NT 10.0; Win64; x64 (Windows 10 and 11 both) |
| macOS | Macintosh; Intel Mac OS X 10_15_7 |
| Linux | X11; Linux x86_64 |
| ChromeOS | X11; CrOS x86_64 14541.0.0 |
| Android | Android 10; K (real device model replaced with the letter K) |
A before/after comparison makes the effect concrete. A real Chrome-on-Android UA used to look like this:
Mozilla/5.0 (Linux; Android 16; Pixel 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.7499.96 Mobile Safari/537.36
After reduction, the same device reports:
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Mobile Safari/537.36
The real Android 16 build and the Pixel 9 model name are both gone, and everything after the major version — 0.7499.96 — collapses to 0.0.0. The major version (143) survives, because sites legitimately need it for compatibility branching; it's the only piece of version detail still passively broadcast, and it does still advance when Chrome updates.
Why Google froze it instead of just deleting it
The original 2021 Chromium Blog announcement framed the UA string as having two separate faults: it passively exposed a lot of identifying information on every single request, whether or not any script asked for it, and its unstructured, freeform format made it a maintenance headache that browsers couldn't safely change without breaking sites that pattern-matched against it. Deleting fields outright would have broken every UA-sniffing script overnight. Freezing them to fixed, universally-shared values keeps the string's format intact — old parsers don't crash — while making the specific values useless as an identifying signal, because millions of unrelated devices now emit byte-for-byte the same string.
The rollout was deliberately staged across a long run of Chrome milestones — origin trials first, then phased deprecation, desktop before Android — specifically so sites relying on granular UA data (device model, precise OS build, exact minor version) had time to migrate to an explicit alternative before the old behavior went away for good.
What replaced the removed detail
Nothing was simply thrown away — Chrome built a parallel channel for exactly this information: User-Agent Client Hints (UA-CH). Where the legacy UA broadcasts everything by default, UA-CH inverts the model. A small set of low-entropy hints (brand, mobile flag, platform name) still goes out automatically, but the high-entropy data the reduction removed — full version numbers, exact OS version, device model — is now only released when a server sends an Accept-CH header asking for it, and read via navigator.userAgentData.getHighEntropyValues() on the client. The information exists; it's just no longer volunteered to every server that asks nothing.
Why sites and scripts break
Any code that parsed the UA string for detail beyond "which browser, roughly which major version, mobile or desktop" now gets stale or wrong answers. Device-detection libraries that branched on an Android model string, analytics that logged exact OS build numbers, or QA tooling that trusted navigator.userAgent for precise version checks all silently degrade — they don't error, they just quietly start returning 0.0.0 and K for every user. That's the trade-off: a real privacy win (dramatically less passive fingerprinting surface on every request) paid for with compatibility debt that falls on whoever didn't migrate to UA-CH in time.
The detection angle: a frozen UA tells you less, both ways
For fingerprinting and spoofing detection, reduction has an interesting side effect. Before, the UA's patch version moved forward with every real update, so a claimed build that was wildly out of date was a mild tell. Now the reduced UA is supposed to look static — a trailing 0.0.0 that never budges between patch releases is completely normal, and a fresh install and a months-stale one are indistinguishable from the string alone. That removes one weak signal, but it doesn't remove the ones that matter: a page can still ask the JavaScript engine which rendering engine and version it's actually running via feature detection, entirely independent of what the frozen UA string claims. If a browser's UA claims Chrome 143 but its real, feature-detected engine version is clearly older or newer — or belongs to a different engine family entirely — that mismatch is exactly the kind of contradiction covered in detecting user-agent spoofing. BrowserInsight's kernel check runs that feature-detection probe and shows it side by side with your claimed UA, so you can see directly whether the two agree.
Test it yourself
Open DevTools and run navigator.userAgent. If you're on a recent Chrome (or any modern Chromium browser), everything after the major version should read 0.0.0 — compare that against the four-part build number on chrome://version and you'll see exactly what was withheld. On Android, check whether the device token reads K instead of your real model name. Then compare it against your actual engine version with BrowserInsight's kernel check, which detects your real rendering engine independently of what the (now frozen) UA string claims.
Frequently Asked Questions
Did Firefox and Safari also freeze their User-Agent strings?
No, reduction is a Chromium-specific program; Firefox and Safari still send their traditional, unreduced UA strings. Only Chromium-based browsers (Chrome, Edge, Brave, Opera, and others built on it) apply the frozen values described here.
Does User-Agent Reduction apply to Chrome on iOS?
No. Chrome on iOS is required to use Apple's WebKit engine rather than Chromium's own Blink engine, and the reduction was scoped to Blink-based Chrome — it does not cover Chrome for iOS or Android WebView, both of which keep their traditional UA strings.
Will my site break because of this?
Only if it reads granular UA fields — exact OS build, device model, or minor browser version — directly from navigator.userAgent or the HTTP header. If so, migrate to User-Agent Client Hints, which still provides that detail through an explicit request. Code that only checks browser family and major version is unaffected.
Is a frozen 0.0.0 version itself suspicious?
No — it's the expected default for every real, up-to-date Chromium browser today, so it carries no signal on its own. What's suspicious is the frozen UA disagreeing with independently-detected signals, like the browser's real feature-detected engine version or its client-hints data.
Conclusion
User-Agent Reduction is a quiet but deliberate trade: Chrome kept the UA string's format so nothing catastrophically broke, while replacing every specific, identifying value inside it with a handful of fixed strings shared across millions of devices. The detail didn't vanish — it moved to User-Agent Client Hints, an API that only discloses it when explicitly requested. For anyone doing fingerprinting or spoofing analysis, the practical upshot is that the UA string itself now tells you almost nothing worth trusting on its own; what matters is whether it agrees with the signals a real browser can't easily fake.
Recommended Reading:
