You can't change Chrome's TLS fingerprint from a setting, a flag or an extension, because the handshake is built inside the network stack before any page code runs. Our engine, Tesseract Chrome, could be patched to do it, and we decided not to. Measured against Google's own unbranded build of the same version, on the same machine, our JA4 came out byte-identical, and that is the result we want.
What a TLS fingerprint is made of
Before a browser sends a single HTTP header to a site, it opens a TLS connection with a message called the ClientHello. That message lists the TLS versions the browser speaks, its cipher suites, its extensions, its supported groups and the application protocols it can run on top (ALPN, usually h2). A server can hash that list and get a short string that says which TLS library, and roughly which version of it, made the connection.
JA3 was the first popular hash. JA4 is the newer one. Ours reads:
t13d1518h2_8daaf6152771_4980c97edce0
Read left to right: TLS 1.3, a domain name in SNI, 15 cipher suites, 18 extensions, and h2 as the first ALPN value. The two hashes after it cover the cipher list and the extension set. Our TLS fingerprint tool explains each part against your own connection.
Why Chrome has no setting for it
Chrome's TLS comes from BoringSSL, compiled into the browser. There is no preference, policy or command-line switch that reorders its ciphers or drops an extension, and an extension runs far too late to touch it: by the time any JavaScript exists, the handshake is over.
So the ways people "change" it are all outside the browser. A scraping library such as curl_cffi or uTLS rebuilds a Chrome-shaped ClientHello in a different program. A proxy that decrypts traffic opens its own TLS connection to the site, and the site then reads the proxy's handshake. Or you patch Chromium and rebuild it, which is the one route open to us, since our engine is patches on stock Chromium source.
Every profile is drawn from one real computer, not from separate listsIn Mosaic: Machines that exist. GPU, screen, CPU and fonts from one real device. Free holds 3 profiles. Pro is $49 a month for any number.
Mosaic is a desktop app
Email yourself the link and open it on your computer.
How it works: Machines that exist
Why we did not patch it
Every real Chrome of a given version sends the same ClientHello shape. That is the point a per-profile TLS setting misses. Two of our profiles with two different handshakes are not two ordinary Chrome users. At most one of them looks like Chrome. The other is the only browser on the internet with that handshake, which is the opposite of what a profile is for.
It also breaks the claim the profile makes everywhere else. A profile says, in its User-Agent and its client hints, that it is Chrome of a particular major version. A network-level detector can compare the handshake with that claim before a single byte of JavaScript runs. A TLS persona that drifts from the version being claimed is a contradiction the site reads first, and nothing done later in the page can take it back.
The same reasoning covers HTTP/2. After the handshake, Chrome sends a SETTINGS frame with its own values in its own order, and Akamai's HTTP/2 fingerprint reads that. We leave that alone too, for the same reason.
What we measured
This was an argument until we measured it. One Mosaic profile and Google's Chrome for Testing of the same major, same machine, same minute, both read by the JA3/JA4 echo row of our detection catalogue:
ours JA4 t13d1518h2_8daaf6152771_4980c97edce0
stock JA4 t13d1518h2_8daaf6152771_4980c97edce0
Identical, including the extension hash: 15 cipher suites, 18 extensions, ALPN h2.
The JA3 strings differed (995f48479d09 against 624b4feda192), and that was expected rather than a finding. JA3 hashes the extensions in the order they were sent, and Chrome shuffles that order on every connection, so two connections from one binary disagree on JA3 as well. Chrome also sends GREASE values, deliberately meaningless entries, in several fields. A fixed JA3 was never something a real Chrome had, and our engine inherits the shuffling unmodified.
One number did move, against the wrong control. Google Chrome one major older, on the same machine, read t13d1517h2: seventeen extensions where the newer one sends eighteen. Chrome's own TLS stack changes between majors. That is why we only ever compare our engine with a Chrome of the same major, and why reading that one-extension gap as a tell would have been a mistake.
The one case where your handshake does change
Mosaic can send a profile's traffic through a debugging inspector such as Proxyman, Charles or mitmproxy, from Settings › Network. An inspector that decrypts HTTPS has to open its own TLS connection to each site, so while inspection is on, sites read the inspector's handshake, not Chrome's. That is fine for debugging your own pages. It is not how you want an account you care about to meet a site, and it is worth knowing before you leave inspection switched on.
An ordinary proxy is different. An HTTP CONNECT tunnel or a SOCKS5 proxy carries the browser's encrypted connection without opening it, so the site sees the browser's own ClientHello whichever exit it comes from.
When we would add the switch
We would revisit this with evidence that a specific detector reads a handshake we send and scores it worse than stock Chrome's. We have not seen one. Until then the missing setting is deliberate: the handshake that blends in is the one Chromium already sends, and the fingerprint work belongs in the values a page can read, drawn from real hardware and matched to the exit. What any anti-detect browser can and cannot change is set out in what an anti-detect browser is.
