JA3 and JA4: the TLS fingerprint your anti-detect browser doesn't hide

What JA3 and JA4 are

Every HTTPS connection starts with a TLS handshake: your browser sends a packet called ClientHello that tells the server which ciphers it supports, in what order, which extensions it uses, which elliptic curves it accepts, and which application protocol it prefers (the ALPN). That packet goes out before any HTML, cookie, or line of JavaScript.

JA3 and the newer JA4 are ways of boiling thatClientHello down into a fingerprint. They take the cipher list, the order of the extensions, the curves, and the ALPN, and turn it all into a hash. Every combination of browser + version + operating system produces a characteristic JA3/JA4 — real Chrome has one, Firefox has another, and the Chromium bundled inside an Electron app has a third that screams "this is not an ordinary browser".

Why the typical anti-detect browser doesn't cover this

Most anti-detect browsers are built on top of Chromium itself (sometimes packaged with Electron). They do a great job of rewriting what a site can read via JavaScript. But the ClientHello is assembled by the runtime's TLS library, not by JavaScript — and JavaScript has no way to rewrite it. The result: no matter how perfectly the tab looks like Chrome, the TLS packet that goes out on the wire carries the signature of the engine that bundled the browser.

Serious trackers — Akamai (used by Meta), Cloudflare, DataDome — collect the JA3/JA4 on the very first packet. If it doesn't match any real Chrome, or worse, if it matches a known automation signature, you're flagged before the page even renders.

The mistake that multiplies the problem: TLS and user-agent out of sync

There's an even subtler trap, and it catches even people using tools thattry to touch the TLS. Say your profile advertisesChrome/126 in the user-agent, but the TLS going out imitates aChrome/131. Each one, on its own, looks legitimate. The problem is that the detector reads both and compares them: a real Chrome 126 would never emit the TLS of a Chrome 131. That contradiction is a strong tampering signal — and it triggers the reCAPTCHA loops, the Cloudflare challenges, and the "verify it's you" prompts.

How AlterAntiX solves it

AlterAntiX intercepts each profile's HTTPS traffic through a small local proxy (a Go binary) that re-emits the ClientHello using the utls library — the same technique serious impersonation tools rely on. Instead of the bundled Chromium's generic TLS, the packet that goes out on the wire reproduces the ciphers, extension order, ALPN, and GREASE of a real Chrome.

And most important: the TLS preset is matched to the profile's Chrome version. AlterAntiX works with exact presets — Chrome 120, 131, and 133 — and keeps the user-agents aligned to those versions, precisely so you never fall into the "the UA says one thing, the TLS says another" contradiction. Each profile runs its own proxy, so profiles in different countries can use different proxies and presets at the same time.

Where limits still remain (and why being honest about it matters)

We don't sell magic. utls faithfully replicates theClientHello, but the exact ordering of HTTP/2 SETTINGSframes isn't reproduced with 100% fidelity — and top-tier detectors, like the Akamai Bot Manager Enterprise, look at that too. In practice, for the targets most people face (Meta Ads, Google, e-commerce, account verifications), aligned TLS already removes the signal that takes down the session. But you deserve to know where the frontier is.

In our own tests, a Chrome 131 profile with the chrome_131 preset passes bot-detector.rebrowser.net with no leaks, logs into Gmail normally, and creates a new Facebook account without getting stuck in the reCAPTCHA Enterprise loop. That's the result of aligning both layers — not hiding one and hoping.