お使いのブラウザーの TLS フィンガープリント（JA4）

What a fingerprint is

Every TLS connection starts with a ClientHello: the client lists the protocol versions, cipher suites, extensions, key-exchange groups, signature algorithms and application protocols (ALPN) it supports. None of that is secret, but the exact combination, and often its order, is characteristic of the TLS library and its version — Chrome's BoringSSL, Firefox's NSS, Apple's stack, OpenSSL, Go, Java. A server, a CDN or a firewall can therefore tell a browser from a script that claims to be one, whatever its user agent says. JA4, published by FoxIO, is the fingerprint most widely used for that today, and Vercel, which serves ecdsa.com, computes it for every connection.

How JA4 is built

A JA4 such as t13d1516h2_8daaf6152771_e5627efa2ab1 has three parts. The first is readable: t for TLS over TCP (q for QUIC, d for DTLS), 13 for the highest version offered, d when a server name was sent (i when not), the number of cipher suites and of extensions, and the first and last character of the first ALPN value (h2). The second part is the first 12 hex digits of a SHA-256 over the cipher suites, sorted; the third, the same over the sorted extensions — without SNI and ALPN — plus the signature algorithms in the order sent. Sorting is what makes JA4 stable: browsers randomise the order of their extensions and add GREASE values (RFC 8701) precisely to stop servers relying on details, and JA4 ignores both. The raw forms, JA4_r and JA4_ro, show the lists themselves, sorted or in the order sent.

Where your own fingerprint comes from

A web page cannot see the ClientHello its own browser sent: TLS happens below the page. The server that received it can. When you press Show my fingerprint, the page asks ecdsa.com's route /api/tools/tls-fingerprint, which reads the x-vercel-ja4-digest header that Vercel's edge adds to each request it forwards — Vercel replaces any value a client sends in that header, so it cannot be spoofed from the browser. The route returns the value as it is and keeps nothing. A copy of the site running anywhere other than Vercel (a developer's machine, another host) has no such header, and the page says so instead of showing a made-up value.

Reading a JA4 or a ClientHello

The other two tabs work entirely in your browser. Read a JA4 takes a hashed fingerprint and explains each field, or a raw JA4_r or JA4_ro, recomputes the hashes and checks that the counts and flags agree with the lists. Read a ClientHello takes the bytes a client sent, as hex — a TLS record, a bare handshake message, or DTLS — for example copied from Wireshark, and computes every JA4 form from them, listing the suites, extensions (named from the IANA registry), signature algorithms, the server name and ALPN. The recorded examples are a headless Chrome 155 and curl with OpenSSL 3.6; the first example of the JA4 tab is the one in FoxIO's specification.

What the tool does not do

It implements JA4 itself, licensed BSD 3-Clause. The other methods of the JA4+ family — JA4S for servers, JA4H for HTTP, JA4X for certificates and the rest — are under FoxIO's own licence, which forbids commercial use without an agreement, so they are not implemented. A fingerprint identifies software, not a person, but it is also not proof: a library can be made to mimic another, and intercepting proxies or antivirus software replace your browser's ClientHello with their own — which is why the fingerprint Vercel sees may not be your browser's at all.

What leaves your browser

Show my fingerprint makes one request to ecdsa.com; nothing from the page goes with it, and the answer is not stored, logged or cached. Pasted fingerprints and ClientHellos never leave the page; share links keep them after the # of the address, which browsers do not send to a server. To see whether your browser's key exchange is post-quantum — the part of the handshake JA4 summarises only as a hash — use the post-quantum browser check.