What Is TLS Fingerprinting? JA3 and JA4 Explained

What Is TLS Fingerprinting?

TLS fingerprinting is a technique that identifies the software making an HTTPS connection by analyzing the unique characteristics of its TLS handshake. When your browser, scraping library, or automation tool opens a secure connection to a website, it sends a “Client Hello” message that reveals specific details about its TLS implementation. These details — the cipher suites offered, the extensions included, the order they appear in — form a fingerprint that can distinguish Chrome from Firefox, Python’s requests library from a Go HTTP client, and a real browser from a bot.

TLS fingerprinting operates below the application layer. It happens before any HTTP headers are sent, before any cookies are exchanged, and before any JavaScript executes. This makes it one of the earliest and hardest-to-spoof detection signals available to websites.

How TLS Fingerprinting Works

Every HTTPS connection begins with a TLS handshake. The first message from the client — the Client Hello — contains several fields that vary by implementation:

Client Hello Components

TLS version — The protocol version the client supports (TLS 1.2, TLS 1.3, etc.).

Cipher suites — An ordered list of encryption algorithms the client supports. Chrome, Firefox, and Safari each offer different cipher suites in a different order. Python’s requests library offers yet another set.

Extensions — TLS extensions provide additional capabilities. Common ones include Server Name Indication (SNI), supported groups (elliptic curves), signature algorithms, and Application-Layer Protocol Negotiation (ALPN). The set of extensions and their order are highly client-specific.

Supported groups — The elliptic curves or key exchange groups the client supports, listed in preference order.

Signature algorithms — The hash and signature algorithm combinations the client accepts for certificate verification.

Compression methods — Though mostly deprecated, the listed compression methods contribute to uniqueness.

JA3: The Standard TLS Fingerprint

JA3, developed by Salesforce’s threat research team, was the first widely adopted TLS fingerprinting method. It creates a fingerprint by concatenating five fields from the Client Hello:

  1. TLS version
  2. Cipher suites (as a comma-separated list)
  3. Extensions (as a comma-separated list)
  4. Elliptic curves
  5. Elliptic curve point formats

These fields are joined with commas, and the resulting string is hashed with MD5 to produce a 32-character fingerprint. For example, Chrome on Windows might produce a JA3 hash of 773906b0efdefa24a7f2b8eb6985bf37, while Python’s requests library produces a completely different hash.

JA3S: Server-Side Fingerprint

JA3S applies the same concept to the server’s response (Server Hello). The combination of JA3 (client) and JA3S (server) creates a more specific fingerprint pair.

JA4: The Next Generation

JA4, developed by FoxIO, improves on JA3 in several ways:

  • Human-readable format — Instead of opaque MD5 hashes, JA4 produces structured strings that encode the TLS version, SNI type, number of cipher suites, number of extensions, and ALPN values in a readable format.
  • Sorted components — JA4 sorts cipher suites and extensions, making the fingerprint more stable across minor client variations.
  • Multiple fingerprint types — The JA4+ family includes JA4S (server), JA4H (HTTP client), JA4L (light distance), JA4X (X.509 certificate), and JA4SSH (SSH).
  • Better for analysis — The structured format lets analysts quickly understand what type of client produced the fingerprint without looking up a hash.

JA4 is increasingly adopted by security platforms and anti-bot services as a more robust successor to JA3.

Why TLS Fingerprinting Matters for Proxy Users

Exposing Non-Browser Clients

The most impactful use of TLS fingerprinting is distinguishing real browsers from HTTP libraries and bots. When you use Python’s requests library, Go’s net/http, or Node.js axios behind a proxy, the TLS fingerprint reveals the actual client software — regardless of what the User-Agent header claims.

Setting User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0.0.0 in your headers is meaningless if the TLS fingerprint shows a Python SSL implementation. The server sees the mismatch before processing a single header.

Proxy-Transparent Detection

TLS fingerprinting works through proxies. When you connect through an HTTP CONNECT proxy or SOCKS5 proxy, the TLS handshake occurs directly between your client and the destination server. The proxy tunnels the encrypted traffic but does not modify the Client Hello. This means the destination sees your client’s true TLS fingerprint regardless of the proxy.

This is a critical point for proxy users. Even premium mobile proxies from DataResearchTools — which provide excellent IP-level trust — cannot change your TLS fingerprint. The IP layer and the TLS layer are independent, and both need to be consistent for effective stealth.

Linking Sessions Across IPs

Like browser fingerprints, TLS fingerprints can link sessions across different IP addresses. If your scraper produces a distinctive TLS fingerprint and you rotate IPs between requests, the target site can still identify all requests as coming from the same client software.

How to Match Browser TLS Fingerprints

Several approaches exist for producing authentic browser TLS fingerprints:

Use Real Browsers

The most reliable method. Tools like Puppeteer (with undetected-chromedriver), Playwright, and headless Chrome produce genuine Chrome TLS fingerprints because they use Chrome’s actual TLS implementation. The fingerprint matches real Chrome traffic because it is real Chrome traffic.

TLS Fingerprint Libraries

Specialized libraries modify the TLS handshake to mimic specific browsers:

  • curl_cffi (Python) — A Python library that wraps curl-impersonate, producing Chrome or Firefox TLS fingerprints
  • curl-impersonate — Modified curl builds that replicate specific browser TLS behavior
  • utls (Go) — A Go library that allows customizing TLS Client Hello messages to match browser profiles
  • tls-client — A cross-platform library for custom TLS fingerprints

These tools let you make HTTP requests from lightweight clients while presenting a TLS fingerprint identical to a real browser.

Anti-Detect Browsers

Multi-accounting tools like Multilogin and GoLogin use full browser engines, inheriting their authentic TLS fingerprints. Since each profile runs in a real browser context, the TLS fingerprint matches the browser version naturally.

TLS Fingerprinting Limitations

TLS fingerprinting is not perfect:

  • Browser updates change fingerprints. Every Chrome version update potentially changes the cipher suite list and extensions. Fingerprint databases must be continuously updated.
  • Shared fingerprints. Many users run the same browser version on the same OS, producing identical TLS fingerprints. The fingerprint identifies the client software, not the individual user.
  • TLS 1.3 reduces signals. TLS 1.3 simplifies the handshake, offering fewer cipher suites and extensions. This reduces the entropy available for fingerprinting, though JA4 still extracts meaningful signals.
  • Corporate environments modify TLS. Proxy appliances, antivirus software, and corporate firewalls can intercept and modify TLS handshakes, creating misleading fingerprints.

Practical Example

You are scraping a major e-commerce site using Python with the requests library, routed through a mobile proxy from DataResearchTools. The site’s defense stack evaluates:

  1. IP check — Mobile carrier ASN, passes with high trust
  2. TLS fingerprint check — Python SSL implementation detected, does NOT match the Chrome User-Agent in the headers
  3. Result — Request blocked despite the trusted IP

Switching to curl_cffi with a Chrome fingerprint profile resolves the mismatch. The same mobile proxy now presents both a trusted IP and a matching TLS fingerprint, and the request succeeds.

Key Takeaway

TLS fingerprinting identifies client software through the TLS handshake, operating independently of IP addresses and HTTP headers. It is one of the earliest signals in the detection chain and cannot be circumvented by proxy usage alone. For effective stealth, the TLS fingerprint must match the claimed browser identity, and this must be consistent with the IP type. Combining genuine browser TLS fingerprints with trusted mobile proxy IPs creates the strongest possible profile.

Return to the Proxy Glossary for more terms and definitions.

Need trusted IPs to complete your stealth stack? DataResearchTools provides mobile carrier proxies that pair perfectly with browser TLS fingerprinting tools. View plans to add the IP trust layer.

Related Reading

Scroll to Top