An old browser build reads as automated
Automation stacks pin their browser versions and update late. So do managed corporate machines and Linux distribution packages — which is how a perfectly ordinary person ends up in the same bucket as a scraper.
Open your browser's About page, let it update, and restart it. If the challenges started recently and nothing on your machine changed, a browser that quietly stopped updating some months ago is one of the few explanations that fits that exact description.
A challenge reads your browser's version from several places at once: the user-agent string, the client-hint headers, and the presence or absence of features that shipped in a known release. Those three have to agree, and their value has to be plausible for the day the request arrived.
Being behind is not evidence of anything on its own. What makes it useful to a vendor is correlation: automation frameworks pin a browser build so their tests stay reproducible, and they update it on their own schedule rather than the browser's. A build that is six months old is disproportionately likely to be pinned.
How do I find out which version I’m on?
Every browser puts this in the same conceptual place and calls it something slightly different, which is why people give up looking.
- Chrome, Edge, Brave, Opera and other Chromium browsers. Menu → Help → About. Opening that page also triggers an update check, so it is both the diagnosis and half the cure. Note the first number only; that is the major version and the only part this site compares.
- Firefox. Menu → Help → About Firefox. Same behaviour: opening it checks for an update.
- Safari. The version follows macOS, so the answer is in System Settings → General → Software Update rather than in the browser. A Safari that cannot be updated means a macOS that cannot be updated.
One thing worth knowing before you go looking: a browser that says it is up to date can still be behind, if it downloaded an update and is waiting for you to restart it. Restarting is not optional here — the running process keeps the old build until it stops.
What “current” means here
This site compares your major version against a written assumption about what is current, dated to the edition on every page's test-distance band. That assumption is not a measurement, it goes stale on its own, and it is published on the assumptions page along with everything else this site assumes.
The threshold is four releases. On Chromium's cadence that is roughly a quarter of a year. The number is a judgment, not evidence, and the assumptions page says so.
There is a consequence you should know about, because it affects how much to trust your own row: if this page has not been updated in a while, the assumption behind it is old, and an old assumption fires this row on a browser that is perfectly current. That failure mode is the reason the edition date is printed on every reading rather than buried. The assumptions page carries the numbers themselves.
Why does a bot check care about the version at all?
Not because old software is insecure — that is a different concern with a different remedy. The reason is narrower and more mechanical: a version is a claim your browser makes about itself, and it is a claim that can be checked against evidence.
A browser announcing version N should also have the features that shipped in version N and lack the ones that came later. It should send client-hint headers consistent with that string. It should behave, in a handful of small observable ways, the way that build behaves. A real browser satisfies all of that automatically because it is that build. Something claiming to be that build has to satisfy it deliberately, and rarely satisfies all of it.
So the version is useful to a vendor twice: once as a weak signal on its own, and once as an anchor for a much stronger consistency check. That second use is why a rewritten user-agent string is worse than an honest old one.
When it is not your choice
Three common cases where the update is held and you cannot release it:
- A managed work machine on an enterprise update channel. Your browser's About page will say that updates are managed by your organisation, and that sentence is the one to forward to whoever manages it.
- A Linux distribution package. Stable distributions freeze browser versions for months. The vendor's own repository, a Flatpak, or a Snap will track upstream instead.
- An operating system that no longer receives the current browser at all. On an old macOS or an unsupported Windows, the last build you can install is the last build you can install, and no setting changes that.
What if my operating system is the thing that is stuck?
This is the case with the least comfortable answer, and it is common enough to deserve a straight one. On a Mac too old for a current macOS, Safari stops where the operating system stops. On an unsupported Windows, the current Chromium builds will not install.
The practical route out is a browser whose support window is longer than your operating system's. Firefox maintains an extended-support release, and several Chromium browsers keep older platforms alive longer than Chrome itself does. That is not a permanent fix — it moves the wall rather than removing it — but it typically buys years, and it is the only thing on this page that helps at all when the hardware cannot be replaced.
It is also worth being clear about what this row is and is not costing you. An old build contributes to being challenged; it is rarely the whole reason on its own. If your reading ranks it below your address or your VPN, fix those first — they are cheaper and they will change more.
Why a user-agent switcher makes this worse
The intuitive response to “my version reads as old” is to change what the browser says. It is the wrong move here and the reason is worth spelling out, because these extensions are frequently recommended for exactly this symptom.
Changing the string changes one of the three places a version is read from. The client-hint headers still describe the real build. The features present in the page still describe the real build. So a check that compares them finds a browser claiming one version while behaving as another — which is not an old browser, it is an inconsistent one, and inconsistency is the single strongest thing a vendor can act on.
The same applies to “privacy” extensions that generalise the user agent as a side effect. If this row fires on a browser you know is current, that is where to look first.
Browser build
Your browser build is old enough that checks treat it as suspicious.
- Open your browser's About page and let it update, then restart it.
- On a work machine the update may be held by policy. The About page will say so, and that is the sentence to send to whoever manages it.
- On Linux, a distribution package can lag the upstream release by months. The vendor's own repository or a Flatpak will be current.
A row's place on your reading is one multiplication, and both halves of it are published. Neither half is a measurement.
- Surprisal −log₂ of an assumed probability of 0.1400 for “the browser build is more than four releases behind”
- 2.84 bits
- Challenge weight A browser build well behind current — how much a bot check is judged to act on it
- 0.45
- Rank The product. It orders the rows and nothing else.
- 1.28
Why that assumption
Managed machines, delayed enterprise channels and Linux distribution packaging all hold browsers back. Assumed from update-channel practice.
We think this one is probably wrong
The four-release threshold is arbitrary. It was picked because it is roughly a quarter of a year on Chromium's cadence, which is a reason but not evidence.
Why that weight
Automation stacks pin their browser versions and update late, so version lag correlates with automation from the vendor's side. It also describes a great many ordinary people on managed machines, which is the whole complaint this site exists to answer.
Every assumption, with its number → · Every weight, and what is deliberately not measured →
Questions about the “Browser build” row
- Why does an old browser make websites think I’m a bot?
- Because automation stacks pin their browser builds so their tests stay reproducible, and update them on their own schedule rather than the browser's. A build that is well behind is therefore more likely, from a vendor's point of view, to be pinned than merely neglected. On its own it is a weak signal; its bigger use is as an anchor for checking whether the rest of the browser behaves like the version it claims.
- How far behind does a browser have to be before it matters?
- This site fires the row at more than four releases behind, which is roughly a quarter of a year on Chromium's cadence. That threshold is a judgment rather than a measurement, it is published with the reasoning, and it is dated — because an assumption about what counts as current goes stale on its own and will eventually fire on a browser that is perfectly up to date.
- My work laptop won’t let me update the browser. What can I do?
- Open the About page and read the line that says updates are managed by your organisation — that sentence is the useful artifact, because it is what whoever manages the machine needs to see. This row belongs to the machine's policy, not to you, and your reading marks it that way so you are not left hunting a setting that does not exist on your account.
- Should I use an extension to change my user-agent string?
- No. The version is read from three places at once — the string, the client-hint headers, and which features the browser actually has — and an extension changes only the first. The result is a browser claiming one build while behaving as another, and a contradiction is acted on far harder than an old build ever was. If this row fires on a browser you know is current, a switcher is the first thing to turn off.
- My Mac is too old for a newer Safari. Is there anything to do?
- Move to a browser whose support window outlasts your operating system's — Firefox's extended-support release, or one of the Chromium browsers that keeps older platforms alive longer than Chrome does. That pushes the wall back rather than removing it. And check the ranking first: if your address or your VPN is above this row, those are cheaper to fix and will change more.
READ AT PRIOR TABLE ED. 1.0.0 · 2026-10-13 · ASSUMED, NOT MEASURED
The rank is taken against 15 written assumptions about how common each value is and 16 written weights about how much each one matters. 9 of them we think are probably wrong. Real counts from the browsers these sites have read appear beside a row, never inside its rank. Read the assumptions →
The rows you cannot fix from a settings page
A VPN you need for work, an address your ISP shares with a thousand other subscribers, a laptop with no graphics chip, a hardened profile that breaks the sites it was meant to protect — none of these have a checkbox. What is left is to present a reading that is internally consistent and ordinary on purpose, instead of one that is accidentally strange.
Donut Browser does that at the engine level: its Wayfern Chromium fork applies the fingerprint through CDP injection rather than patching JavaScript in the page, and it refuses to launch a profile whose proxy exit country, time zone and language contradict the profile's own fingerprint — which is the top row of most readings on this site. It is AGPL-3.0, it has no telemetry of any kind, and it runs on macOS, Windows and Linux.
Stated plainly: this site has no test results showing what any particular anti-bot service does with any particular browser, and neither does Donut Browser's own repository. What can be checked is the source, which is public.
Free · AGPL-3.0 · github.com/zhom/donutbrowser