User agent spoofing: why 2 Chrome versions behind is a tell

Changing the user agent is the oldest trick in automation, and it still appears in almost every scraping tutorial. It was designed for a web where the string was the only place a browser named itself. Today the same browser names its version in two request headers, in a JavaScript API and in the shape of its TLS handshake, and a string changed in one place disagrees with all the others. There is a second failure that needs no spoofing at all: a version that is correct everywhere but has stopped moving.

What is user agent spoofing?

User agent spoofing is replacing the browser name, version or platform a browser reports with a different one, usually by overwriting the User-Agent header. In current Chrome the version appears in three places, and only the first is the string people change.

1. The User-Agent string. Chrome reports only the major version followed by zeros, such as Chrome/152.0.0.0 in real Chrome 152 on 8 September 2026, and the string still carries the platform.
2. The client hints. The Sec-CH-UA header lists the brands with their major version on every request, Sec-CH-UA-Full-Version-List gives the full build number when a site asks for it, and navigator.userAgentData returns the same values to scripts.
3. The TLS handshake. The ClientHello a browser sends depends on its build and on the features enabled for that version, and a server reads it before the page exists.

A spoofed string changes the first place only. The client hints and the handshake still come from the engine that is actually running. Why rotating the string contradicts the engine is covered in Random user agent.

Why does an outdated Chrome version stand out?

An outdated Chrome version stands out because Chrome updates itself, so most real users sit on the newest two versions. Since September 2026 the window is short: Google's announcement of the two-week release cycle states that "Starting September 2026, Chrome will move to a two-week release cycle", beginning with Chrome 153 on 8 September. Two versions behind now means four weeks behind.

The drop is steep. Chrome's numbered desktop versions together held 60.46 percent of desktop browsers in September; within them, 152 and 153 together held 60.1 percent, 151 held 9.9 percent and 150 held 2.4 percent. StatCounter lists 68 Chrome versions for the month, and apart from 151 to 154 none holds more than 3 percent of desktop Chrome.

Our own engine sat in that tail. On 10 September 2026 the newest engine we shipped was 151.0.7922.99, while real Chrome on the same machine had already updated to 153.0.8010.37. A version that stops moving drifts into that tail by itself, one release every two weeks, whatever the other values say. The engine moved to 154 on 20 September, and a profile now takes the new engine at its next start, the way a real Chrome installation applies its update.

A frozen build carries more than an old number. Until 10 September about a quarter of new profiles were created on an older package that lacked later fixes, some of which changed what a page can read. Since that date a new profile starts on the current build.

Which client hints have to agree?

The client hints have to agree with the user agent string and with each other, down to the order of the brands. Chrome's source for the brand list builds Sec-CH-UA from three entries: Chromium, Google Chrome and a decoy brand. The decoy's punctuation, its version number and the order of all three are derived from the major version.

We computed the rows from that source; the 152 row matches what real Chrome 152 reported in our reading of 8 September 2026. A user agent string that says 153 next to the brand list of 151 names two versions in one request. The same holds for the full version list, which carries the complete build number, and for the platform: Sec-CH-UA-Platform-Version separates Windows 10 from Windows 11, a difference the user agent string does not show at all, as Microsoft's detection guide points out.

These are the pairs that browser fingerprint signals are built on. A checker does not need to know what your version should be; it compares the string, the hints and the script's answer, and any two of them that disagree are enough. Spoofing the location, as opposed to the version, is covered in Geolocation and timezone spoofing.

How does the TLS fingerprint change with the version?

The TLS fingerprint changes with the version whenever Chrome switches a TLS feature on for a release, often through a field trial rather than a code change. On 25 August 2026 branded Chrome 151 sent 17 TLS extensions where our Chromium 151 build sent 16, so our handshake matched Chrome 150 while the user agent said 151. The JA4 fingerprint of a fork covers that measurement and what changed afterwards. A spoofed user agent string makes the same contradiction on purpose, because the handshake always belongs to the engine underneath.