Account

TLS fingerprint test: JA3, JA4, HTTP/2, HTTP/3 and TCP

Before any page code runs, our server reads how your browser opens the connection. A browser can call itself anything, but its TLS handshake and HTTP/2 settings show which engine really sent the request, and the first TCP packet gives away the system that opened the connection. We also offer the browser HTTP/3 and watch whether and how it moves to QUIC.

Checking your browser…

What this test reads

When your browser opens an HTTPS connection, it first sends a ClientHello: the TLS versions, cipher suites and extensions it supports, in its own order. Our separate check server reads this message before the page code runs and turns it into two fingerprints, JA3 and JA4, plus the family of the TLS stack: Chrome and other Chromium browsers, Firefox, Safari and WebKit, or a program.

Over HTTP/2 the browser also sends its own SETTINGS and orders the pseudo-headers of the request in its own way. Chromium, Firefox and Safari each do it differently, and HTTP libraries in Python, Go or Node do it differently again. The page compares both with the browser your User-Agent names.

Deeper still is TCP itself. The first packet of a connection carries the habits of the system that opened it: the initial TTL, the window size, the MSS and the order of the TCP options. From the TTL and the option order our server names the system family (Windows, macOS and iOS, Linux and Android) with SpoofLens' own signature and compares it with the system in the User-Agent. It also compares two round trips: how long the network path takes as our server measures it, and how long the page itself waits for an answer. A proxy between the browser and the server pulls these two apart.

The page also checks QUIC, the transport HTTP/3 runs on. Our server offers the browser HTTP/3 and watches whether it moves to it, which address the QUIC connection comes from and how the browser built its QUIC handshake. Plenty of honest people have no QUIC: companies and some networks block UDP. So no QUIC on its own means nothing; what matters is the combination: UDP reaches us, the browser speaks HTTP/3 and it never tried, or QUIC came from another address.

How to read the result

  • TLS stack: the browser family the handshake belongs to. "Not a browser" means a script, an HTTP library, an antivirus or a corporate proxy that opens HTTPS connections itself.
  • JA4 and JA3: short fingerprints of the handshake. The same browser version on the same system gives the same JA4, so it is useful for comparing profiles.
  • HTTP/2 looks like: the family the HTTP/2 settings and the pseudo-header order point to.
  • TCP signature: the family of the system that opened the connection and the values of its first packet (TTL, MSS, window, option order). Linux here while the browser says Windows usually means a proxy opened the connection.
  • Round trip: two numbers, the first measured by our server, the second by the page itself on the same connection. They are normally close.
  • QUIC and HTTP/3: whether the browser moved to HTTP/3 after our offer, whose network stack built the QUIC handshake, and 0-RTT when the browser resumed an earlier connection. "The browser did not try" while UDP works most often means a proxy set in the browser.
  • Protocol of each request: what the browser itself says about each request (h2 or h3). The first one usually goes over TCP: the browser learns about HTTP/3 from its answer.
  • Verdict: a green result means the connection fits the browser. A TLS handshake from another browser counts in the full check; so does an HTTP/2 mismatch (since 0.17.0), while TCP and QUIC mismatches are shown as information until we have tested them on real devices.

Further reading

Frequently asked questions

Can I change my TLS fingerprint?
Not from browser settings. The handshake comes from the network code of the browser engine, which is why it shows the real engine even when the User-Agent is changed.
Why does my JA4 change after a browser update?
New versions sometimes add or remove extensions and ciphers. The family stays the same, only the exact fingerprint changes.
My antivirus shows up as "not a browser". Is that bad?
Some antivirus programs and corporate proxies inspect HTTPS by opening the connection themselves, so the site sees their handshake instead of the browser's. That is not spoofing, but sites that defend against bots see the same thing.
What is the TCP signature?
Our own signature: the system family from the initial TTL and the order of TCP options in the first packet, with the window and the MSS shown next to it. Passive system detection from TCP is an old idea; the set of features and the family names are ours.
Why does QUIC not work for me?
Most often the network blocks it: company, school and some guest networks drop UDP. QUIC is also switched off by company policy, by a browser flag, or by a proxy set in the browser, because HTTP and SOCKS proxies do not carry UDP. On its own this is not a sign of spoofing, and the index does not drop for it.
Is anything stored?
No. The handshakes, the first TCP packet and the first QUIC packets are read for this check and forgotten; only daily sums are counted, without the checks themselves.