---
title: "User agent spoofing: why 2 Chrome versions behind is a tell"
description: "User agent spoofing against client hints, TLS and Chrome's two-week release cycle: why a changed string contradicts itself and why a frozen version stands out."
canonical: "https://scalebrowser.net/blog/user-agent-spoofing"
last_modified: "2026-10-21"
published: "2026-10-21"
author: "davide"
category: "detection"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://scalebrowser.net/llms.txt
> Use this file to discover all available pages before exploring further.

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

> User agent spoofing against client hints, TLS and Chrome's two-week release cycle: why a changed string contradicts itself and why a frozen version stands out.

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](https://developer.chrome.com/blog/chrome-two-week-release) 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.

<Evidence source="StatCounter desktop browser version share, September 2026 to date, and Chromium Dash stable dates, read 29 September 2026" href="https://gs.statcounter.com/browser-version-market-share/desktop/worldwide">

| Chrome version | Stable since | Share of all desktop browsers | Share of desktop Chrome |
| --- | --- | --- | --- |
| 154 | 22 September 2026 | 1.87 percent | 3.1 percent |
| 153 | 8 September 2026 | 16.26 percent | 26.9 percent |
| 152 | 25 August 2026 | 20.09 percent | 33.2 percent |
| 151 | 28 July 2026 | 6.01 percent | 9.9 percent |
| 150 | 30 June 2026 | 1.48 percent | 2.4 percent |
| 149 | 2 June 2026 | 0.60 percent | 1.0 percent |

</Evidence>

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](https://github.com/chromium/chromium/blob/main/components/embedder_support/user_agent_utils.cc) 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.

| Major version | `Sec-CH-UA` as Chrome builds it |
| --- | --- |
| 151 | `"Not=A?Brand";v="99", "Google Chrome";v="151", "Chromium";v="151"` |
| 152 | `"Chromium";v="152", "Not?A_Brand";v="24", "Google Chrome";v="152"` |
| 153 | `"Google Chrome";v="153", "Not_A Brand";v="8", "Chromium";v="153"` |
| 154 | `"Chromium";v="154", "Google Chrome";v="154", "Not A(Brand";v="99"` |

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](https://learn.microsoft.com/en-us/microsoft-edge/web-platform/how-to-detect-win11) points out.

These are the pairs that [browser fingerprint signals](/blog/browser-fingerprinting) 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](/blog/ja4-tls-fingerprint) 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.
