TLS fingerprint
In the very first packet of an HTTPS connection (the ClientHello) your browser already lists the cipher suites, extensions and elliptic curves it supports. Hashing those fields gives JA3 / JA4; the SETTINGS frame that opens an HTTP/2 connection can be fingerprinted the same way. All of this happens before any JavaScript runs, and changing the UA does not change it.
- JA4
- JA3 hash
- JA3 string
- HTTP/2 fingerprint
- TLS version
- Source
- Observed at
- Browser as parsed by the server
- Times seen here
- First seen
- Observations of this JA4
- Share from the same browser family
- Browsers sharing this JA4
JA3 (Salesforce, 2017) concatenates TLS version, cipher suites, extensions, curves and point formats in their original order and takes an MD5, so reorder anything and the hash changes. Since Chrome 110 the extension order is shuffled on every connection, so one Chrome's JA3 differs almost every time. JA4 (FoxIO, 2023) sorts before hashing (truncated SHA-256) and puts TLS version, SNI, ALPN and counts into a readable prefix such as t13d1516h2, which makes it very stable per browser family: every Chromium browser (Chrome, Edge, Brave…) shares one JA4, Firefox and Safari have their own. Websites compare JA4 with the UA: a UA that claims Firefox on a handshake that looks like Chrome is an automation tool or anti-detect browser with a swapped UA; this site does the same comparison against its own JA4 ↔ browser-family statistics. To see the fingerprint at all the server has to terminate TLS itself: on a Cloudflare-proxied (orange cloud) hostname the handshake happens at Cloudflare's edge and the origin only sees Cloudflare's own fingerprint (Cloudflare exposes JA4 to Enterprise customers only). That is why fingerproxy runs on a separate DNS-only (grey cloud) hostname which the browser calls cross-origin once; when that endpoint is unreachable we fall back to the third-party check.ja3.zone, which gives JA3 only.