TLS fingerprint (JA3 and JA4)

How it works

Every HTTPS connection starts with a ClientHello message in which the client lists the TLS versions, cipher suites, extensions, curves and other options it supports. Each TLS library fills it in its own way, so Chrome, Firefox, Safari and a Python script all look different at this step. JA3, published by Salesforce engineers in 2017, turns those fields into a hash. Chrome later began shuffling the order of its extensions, which made JA3 values unstable, and JA4 from FoxIO sorts them first and adds readable parts such as the protocol and the number of ciphers.

The fingerprint is taken by the server, or the CDN or firewall in front of it, before any page loads. JavaScript can’t see or change it.

Why it matters when you run several accounts

The TLS fingerprint describes the real browser build. If a profile’s user agent says Firefox but the handshake is Chrome’s, or an automation library connects with its own TLS stack, the server sees the contradiction without running a single script. It is one of the reasons “changing the user agent” on its own doesn’t hold up.

How SoftGlaze Browser handles it

SoftGlaze Browser doesn’t try to fake TLS. Chromium profiles run real Chrome builds, either Chrome for Testing downloaded by version or the Google Chrome installed on your computer, so the handshake is genuinely that of the version the profile reports. When a profile presents as another Chromium brand, the user agent, Client Hints and navigator identity change while TLS and JA4 stay those of the real Chrome underneath, as the editor states. Firefox profiles run real Firefox, with Firefox’s own handshake.