What a new Chrome major actually changes in your fingerprint

Chrome 153 reached the stable channel on 2026-08-26. The AntiBrow kernel builds on it now, and a profile created on a machine that has it reports it. That is a release note, and release notes are boring. The interesting part is what a detector does with the number, because it is not what most people assume.

The user agent is the smallest part of it

Chrome stopped sending a useful user agent a long time ago. The build and patch fields are frozen at zero, so the string reads Chrome/153.0.0.0 on every machine running any 153 build, whatever its actual patch level. Sec-CH-UA carries the major and nothing else. The full four part version exists, but only if the site asks for it by name through Sec-CH-UA-Full-Version-List, which is a high entropy hint and a request the site has to make deliberately.

So the major version is cheap to read and cheap to fake. Nobody serious treats it as evidence on its own. What they do instead is treat it as a claim, and then check that claim against everything a browser cannot lie about as easily.

The claim has to match the binary

Every Chrome major adds and removes web platform surface. A CSS property resolves where it did not before. navigator grows a field. A constructor that threw last release now exists. None of that is configuration. It is compiled into the binary.

A detector that wants to test your user agent does not argue with it. It runs a handful of feature probes and asks whether the answers belong to the version you claimed: CSS.supports() on a property that landed two majors back, the presence of an interface on window, the exact wording of a thrown error. A profile whose user agent says one version while its JS engine answers like an older build has told the site two different things, and that contradiction is worth far more to a scoring model than either value on its own.

This is the whole reason the version has to come from a real build rather than a string edit. The fingerprint is applied in the browser engine, below the JS layer, so the version a site reads and the version actually executing are the same thing. There is no injected override script that can drift from what the engine does.

Why your existing profiles did not move

A new profile picks up the newest build installed for its platform. Existing profiles do not move. The version is pinned in the profile and stays pinned until you change it.

That is deliberate, and the reason is population, not caution. A new major rolls out over weeks. On the day it goes stable, the share of real users on it is small and climbing. A profile that jumps to a brand new major within hours of release sits in a very thin bucket, and it got there while the rest of your profiles stayed behind. If those profiles look related for any other reason, a synchronised jump across all of them is one more reason.

The reverse is the same mistake wearing a different hat: leaving forty profiles on one stale major for half a year. Real people update on their own schedule. Forty of them should look like forty schedules, not one.

So move them when you have a reason to, a few at a time:

import { setProfileKernelVersion } from 'anti-detect-browser'

await setProfileKernelVersion({ profileName: 'ads-us-east', version: '153' })

In the desktop app the same control sits on the environment, under browser core.

Where this does not matter and you should not pay for it

If you run one or two browsers on your own machine and you are not signed into the same platform twice, none of this is your problem. Your real Chrome updates itself, its reported version matches its binary by construction, and it costs nothing. Buying an antidetect browser to fix a version consistency problem you do not have is a bad trade. The reason to run separate engines is separate identities that must not link back to each other, and if that is not what you are doing, keep the money.

A new major will also not rescue a profile that is failing for some other reason. Version is one field among hundreds. If a site is challenging you, the proxy, the account history and the behaviour are all likelier causes, and no browser controls those. We publish dated detection runs rather than promises because that ordering is the honest one.

Check it yourself

Open any profile and read what it reports:

navigator.userAgent
await navigator.userAgentData.getHighEntropyValues(['fullVersionList'])
CSS.supports('animation-timeline', 'scroll()')

The major in the first should match the major in the second, and the third should answer the way a real browser of that version answers. For the rest of the surface, the consistency walkthrough covers what else has to agree, and how anti-bot systems work covers what happens when it does not.