For years, staying anonymous online meant staying one step ahead of browser fingerprinting. But as tracking technologies matured, online platforms moved the battlefield deeper into the network stack.
We recently explained TCP/IP fingerprinting. Now we look at another network-level method that works differently and is harder to contain.
It starts with something most people never think about. About 95% of the requests Cloudflare handled in July 2024 were made over encrypted HTTPS connections. Yet each secure connection begins with an opening message that is sent before encryption starts, and the way your software writes that message can make it recognizable, even when your IP address and cookies change. That is the idea behind TLS fingerprinting.
In this guide, we explain how TLS and JA4 fingerprinting work, how they differ from browser and TCP/IP fingerprinting, and how to defend against them.
What is TLS Fingerprinting?
TLS fingerprinting is the process of identifying and tracking a client, meaning the browser or software behind a connection, based on how it sets up a secure connection with a server. It takes advantage of TLS (Transport Layer Security), the cryptographic protocol that secures most internet connections.
Whenever you visit an HTTPS website, your browser and the server perform a "handshake" to agree on how to encrypt the connection. The handshake starts with a message from your browser called the Client Hello. It lists what your browser supports, such as encryption methods (cipher suites), add-on features (extensions), and other settings.
Because different operating systems, browsers, and TLS libraries (the software that handles encryption) build this list in different ways, the exact combination of values in a Client Hello is often distinctive. A TLS fingerprint combines these differences into an ID for the client software.
Importantly, TLS fingerprinting does not require decrypting the contents of the HTTPS connection. The Client Hello is sent before the encrypted application data begins, so its characteristics can be examined without reading the encrypted content that follows.
The most famous implementation of this idea was JA3, introduced by Salesforce researchers in 2017, and it quickly became the industry standard for TLS fingerprinting. Security teams used it to detect malware, botnets, and unauthorized API clients. Anti-bot services like Cloudflare and Akamai began incorporating JA3 into their detection engines, cross-referencing it with browser fingerprints and IP reputation.
But JA3 has weaknesses. It depends on the exact order of the items in the Client Hello, and Chrome and other browsers began shuffling that order on purpose. The same browser could then produce many different JA3 fingerprints, which made the method less reliable. It is also easy to imitate: anyone can copy a real browser's Client Hello.
JA4: The Next Generation of TLS Fingerprinting
JA4 was built to fix those problems. It sorts the lists before turning them into a fingerprint, so shuffling no longer changes the result, and it captures a few more details. JA4 is actually a family of methods, each covering a different part of the connection:
- JA4 (Client Hello) fingerprints the initial Client Hello message.
- JA4S (Server Hello) fingerprints the server’s response.
- JA4H (HTTP/2 Fingerprint) fingerprints the details of an HTTP request
- JA4X (X.509 Certificate) fingerprints the TLS certificate chain presented by the server.
The one that matters most here is the first, JA4. A JA4 fingerprint has three parts. The first is a readable summary: the connection type, the TLS version, whether a website name was included, how many cipher suites and extensions were offered, and which web protocol the browser prefers. The other two are short codes made from the sorted list of cipher suites and the sorted list of extensions.
Here is an example: `t13d1516h2_8daaf6152771_e5627efa2ab1`.
The first part reads as TLS over TCP (t), TLS version 1.3 (13), a domain name included (d), 15 cipher suites (15), 16 extensions (16), and HTTP/2 preferred (h2).
How JA4 Fingerprinting Works in Practice
When you connect to a site protected by an anti-bot service, the server, or a reverse proxy in front of it such as Cloudflare, reads your Client Hello and works out the JA4 fingerprint before passing the connection on. It then compares the fingerprint against a database of known software: regular browsers, headless browsers, common scripting libraries, and so on.
A script built with a default Python library, for example, will not produce the same fingerprint as a real browser, and the difference is well known. If the fingerprint does not match the browser the visitor claims to be, or matches a known bot, the site can show a CAPTCHA, block the visit, or serve different content.
The real power comes from combining signals. A profile that claims to be Chrome on a Mac but has a fingerprint typical of the curl command-line tool looks suspicious right away. And if a proxy changes your IP address but your JA4 fingerprint stays the same, a site can link your sessions across those IP changes.
Because all of this happens during the handshake, it is completely passive. Nothing runs in your browser, and no page needs to load, so browser extensions, incognito mode, and most privacy tools cannot see or stop it.
TLS Fingerprinting vs Browser Fingerprinting
TLS fingerprinting is related to browser fingerprinting, but they examine different parts of the internet connection to track users.
Browser fingerprinting focuses on information exposed by the browser and, in some cases, the device. This can include screen characteristics, fonts, browser APIs, rendering behaviour, Canvas and WebGL information, timezone, language, and other properties.
TLS fingerprinting, by contrast, looks at the characteristics of the TLS connection itself.
The distinction can be summarised like this:
| Browser fingerprinting | TLS fingerprinting | |
| Primary focus | Browser and device environment | TLS client/implementation |
| Main source | Browser APIs and browser behaviour | TLS handshake |
| Typical layer | Application/browser | Network/security protocol |
| Examples | Canvas, WebGL, fonts, screen size | Cipher suites, extensions, TLS versions, ALPN |
| Requires JavaScript? | Often | No |
READ MORE: Browser Fingerprinting: A Complete Guide
TLS Fingerprinting vs TCP/IP Fingerprinting
TLS fingerprinting also differs from TCP/IP fingerprinting, although both operate closer to the network layer than traditional browser fingerprinting.
TCP/IP fingerprinting examines characteristics of how a device or operating system communicates using network protocols. These can include TCP options, window sizes, packet behaviour, and other characteristics of the TCP stack.
TLS fingerprinting instead examines the TLS handshake that takes place after the underlying network connection has been established.
The distinction is therefore primarily about what is being observed. Both methods can overlap in what they reveal, but they are not interchangeable. TCP/IP fingerprinting can hint at your operating system, while a JA4 fingerprint can hint at the app or software library making the connection. Apps and programming tools often leave recognizable TLS fingerprints because they use different TLS libraries.
| Fingerprinting method | What it examines |
| Browser fingerprinting | Browser and browser-exposed device characteristics |
| Device fingerprinting | Characteristics associated with the underlying device |
| TCP/IP fingerprinting | Network-stack and packet characteristics |
| TLS fingerprinting | Characteristics of the TLS handshake |
| JA4 | A specific method for creating a TLS client fingerprint |
READ MORE: What Is TCP/IP Fingerprinting? - Incogniton
Can an anti-detect browser handle JA4/TLS fingerprinting?
Most anti-detect browsers are designed to manage browser‑level fingerprints, but TLS fingerprinting happens at the network layer, often outside the browser’s control.
If you’re using an anti‑detect browser like Incogniton to manage multiple accounts, you already understand the importance of isolating cookies, local storage, and browser fingerprints. But even a perfectly configured browser profile can be betrayed by its TLS fingerprint.
Some advanced anti‑detect browsers are beginning to integrate TLS fingerprint spoofing by modifying the TLS library or routing connections through a local proxy that rewrites Client Hello messages. When evaluating a solution, ask whether it can produce JA4 hashes that match the emulated environment.
How to Defend Against JA4 Fingerprinting
Managing JA4 fingerprinting requires a holistic approach that aligns your TLS stack with your emulated browser and OS. Here are the primary strategies:
1. Match the TLS Stack to the Browser Profile
The most straightforward defense is to ensure that the actual TLS library used by your browser matches the profile you’re presenting. If your profile says Chrome, the connection should be done how a Chrome browser connects. This is difficult to achieve with standard browsers and its also why anti‑detect browsers must go beyond simple user‑agent spoofing.
2. Use Proxies with Diverse TLS Fingerprints
Residential and mobile proxies can help, but only if their exit nodes run a variety of operating systems and TLS stacks. A proxy that terminates TLS and establishes a new connection to the target server can present its own TLS fingerprint, which may differ from your local one. However, if all your proxy nodes run the same minimal Linux distribution, they may all share an identical JA4 hash, creating a detectable pattern.
For maximum stealth, you need a proxy network that not only rotates IPs but also presents a diverse set of TLS fingerprints that match a range of real browsers and operating systems. Some premium proxy providers now offer “TLS fingerprint rotation” as a feature, ensuring that the JA4 hash changes alongside the IP address, making session linking far more difficult.
3. Leverage Specialized Tools and Libraries
For developers and automation engineers, several open‑source tools can help control the TLS fingerprint. Libraries like tls-client (Go) and curl-impersonate (a modified curl) allow you to mimic the TLS handshake of specific browsers. These tools replace the default TLS stack with one that reproduces the exact cipher suites, extensions, and ordering of a target browser, generating a matching JA4 hash. However, they require careful integration and are not a drop‑in replacement for a full browser environment.
4. Monitor Your Fingerprint Regularly
Because TLS fingerprints can change with browser updates, OS patches, or library upgrades, it’s important to monitor what JA4 hash your setup actually produces. Public test endpoints and open‑source JA4 calculators let you check your fingerprint against known databases. Regularly testing your configuration helps you catch mismatches before they lead to blocks or account bans.
Conclusion
In summary, ignoring the TLS layer is no longer an option for anyone serious about maintaining anonymity or managing multiple accounts.
TLS fingerprinting, and JA4 in particular, is another potent weapon that both parties need to be wary about. But as with all online fingerprinting methods, the most effective defense is a layered one.
ensure that every signal your setup emits, from IP geolocation to TCP parameters to TLS fingerprints to browser APIs, tells a consistent, believable story.
