Skip to content
Free tool · Runs in your browser

TLS checker

The TLS version, cipher suites and key exchange your browser offers, whether it is post-quantum ready and supports Encrypted Client Hello, and whether it speaks HTTP/2 and HTTP/3. Read from a real handshake.

Opens fresh connections to our TLS server (tls.clearcotelabs.com, ports 8443, 8444 and 8446), which reads the handshake your browser sends. The HTTP/3 check makes a few requests to Cloudflare's cdnjs.cloudflare.com. Nothing is stored.

What each result means

Protocol version. The version your browser and our server agreed on. Our server supports TLS 1.3, so that is what any current browser gets. One handshake shows the highest version a client offers, not the oldest it would still accept; that would take deliberately failing handshakes, which a page cannot ask a browser to make.

Cipher suites. The encryption and integrity algorithms your browser offers, in its order of preference; the server picks one. Insecure means broken in practice: RC4, 3DES, single DES, NULL (no encryption), export-grade or anonymous suites. Legacy means CBC mode or RSA key exchange, which has no forward secrecy: anyone who later obtains the server's private key can decrypt recorded traffic. Browsers still offer a few legacy suites for old servers. Signal entries such as TLS_EMPTY_RENEGOTIATION_INFO_SCSV are not ciphers at all.

Key exchange groups. The curves and post-quantum hybrids your browser can use to agree on a key. A X25519MLKEM768 entry (code point 0x11EC) means post-quantum key exchange; X25519Kyber768Draft00 (0x6399) is the pre-standard version Chrome 124 to 130 used.

Encrypted Client Hello. ECH (extension 0xfe0d) hides the name of the site you visit from the network, but only for sites that publish an ECH key in DNS. Chrome and Firefox send the extension on every connection, so its presence gives nothing away.

ALPN and GREASE. ALPN is how the client offers HTTP/2 (h2) inside the handshake. GREASE values are deliberately meaningless entries that Chromium browsers and Safari add to keep servers tolerant of new values; Firefox sends none.

HTTP/2 and HTTP/3. HTTP/2 is checked against our own server, which also records the opening frames as an Akamai-format fingerprint (more on the JA4 page). Our servers do not speak HTTP/3, so that one check fetches a small file from Cloudflare's cdnjs a few times and reads which protocol carried each request from Resource Timing. Cloudflare receives those requests like any other cdnjs download.

What Chrome offers

Measured on Google Chrome 152, 153, 154 and 155 on Linux and 154 on Windows 11 (JA4 t13d1517h2_8daaf6152771_cb7bf5808d99, the same in every one of them): TLS 1.3, 15 cipher suites, key exchange groups X25519MLKEM768, x25519, secp256r1 (P-256) and secp384r1 (P-384), ECH, ALPN h2 then http/1.1, and GREASE. The cipher suites, in Chrome's order; 6 of them are legacy suites kept for old servers, and none is insecure:

TLS_AES_128_GCM_SHA2560x1301TLS 1.3
TLS_AES_256_GCM_SHA3840x1302TLS 1.3
TLS_CHACHA20_POLY1305_SHA2560x1303TLS 1.3
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA2560xc02b
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA2560xc02f
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA3840xc02c
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA3840xc030
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA2560xcca9
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA2560xcca8
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA0xc013CBC mode
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA0xc014CBC mode
TLS_RSA_WITH_AES_128_GCM_SHA2560x009cRSA key exchange, no forward secrecy
TLS_RSA_WITH_AES_256_GCM_SHA3840x009dRSA key exchange, no forward secrecy
TLS_RSA_WITH_AES_128_CBC_SHA0x002fRSA key exchange, no forward secrecy; CBC mode
TLS_RSA_WITH_AES_256_CBC_SHA0x0035RSA key exchange, no forward secrecy; CBC mode

Chrome's HTTP/2 fingerprint is 1:65536;2:0;4:6291456;6:262144|15663105|0|m,a,s,p. Its full list of 17 extensions, and how Edge, Brave and Chrome for Testing differ from it, is on the JA4 fingerprint checker.

Why an HTTP client claiming to be Chrome looks different

The cipher list, the groups and the extensions are written by the TLS library, before any HTTP header exists. A Python or Node script that sends Chrome's User-Agent still opens every connection with its own library's handshake, and the server reads that first.

curl 7.81.0 built on OpenSSL, for instance, offers 31 cipher suites to Chrome's 15, among them DHE and CBC-SHA256 suites that Chrome does not offer; it offers x448 and P-521 but no post-quantum group, sends no ECH and no GREASE, and adds next_protocol_negotiation, an extension browsers removed years ago. Python requests and Node fetch differ again: their JA4s, t13d4312h1_c7886603b240_b26ce05bbdd6 and t13d5911h1_a33745022dd6_1f22a2ca17c4, already show 43 and 59 cipher suites where Chrome has 15, and no HTTP/2 in ALPN. Each of these is plain to see on this page, and the JA4 reference table lists the fingerprints we measured.

Browsers built on Chromium's own network stack send Chrome's handshake because it is Chrome's code, which is the approach Clearcote takes (how).

FAQ

How do I check which TLS version my browser uses?

Run the check above: it opens a fresh HTTPS connection to our server and reports the version the two sides agreed on. Every current browser negotiates TLS 1.3 with a server that supports it. In Chrome you can also open DevTools, the Security (in newer versions Privacy and security) panel, and look at the connection of any page.

What is TLS 1.3?

The current version of the protocol behind HTTPS, published in 2018 as RFC 8446. It removed every cipher suite without forward secrecy and every non-AEAD cipher, cut the handshake to one round trip, and encrypts most of the handshake itself. Its five cipher suites name only the encryption and hash; the key exchange is always ephemeral (EC)DHE, or a post-quantum hybrid.

Is my browser post-quantum ready?

If the check lists X25519MLKEM768 under key exchange, yes: it combines the classical X25519 curve with ML-KEM-768, the post-quantum key-encapsulation mechanism NIST standardized in 2024 (FIPS 203). Current Chrome, Edge, Firefox and Safari offer it. The connection is only post-quantum if the server supports the group as well; if it does not, the two fall back to plain X25519.

What are HTTP/3 and QUIC?

HTTP/3 (RFC 9114) is HTTP carried over QUIC, a transport that runs over UDP instead of TCP and has TLS 1.3 built in. It saves round trips when a connection opens and does not stall every request when one packet is lost, which helps most on mobile and lossy networks. Browsers use it only after a site tells them, through an Alt-Svc header or a DNS HTTPS record, that it is available.

Why does the check say HTTP/3 was not used?

Most often because UDP port 443 is blocked: many corporate networks, some public Wi-Fi and some VPNs and proxies carry TCP only. QUIC can also be turned off by a browser flag, an enterprise policy, or an antivirus product that inspects HTTPS (it can only inspect TCP). In every case the browser quietly falls back to HTTP/2, so pages still load.

Why does my browser still offer CBC and RSA cipher suites?

For servers that support nothing newer. Chrome lists AES-CBC suites and suites with plain RSA key exchange at the end of its list; a server that speaks TLS 1.3 or modern TLS 1.2 never picks them. The check marks them as legacy, not as a failure. RC4, 3DES, NULL and export-grade suites are different: no current browser offers them, and a client that does is marked insecure.

What is the difference between this and the JA4 fingerprint checker?

This page reads the same handshake and tells you what is in it: version, ciphers, groups, extensions, HTTP/2 and HTTP/3. The JA4 fingerprint checker condenses it into a fingerprint and compares that, part by part, with Chrome and with common HTTP clients.

Clearcote puts this into practice

An open-source Chromium with fingerprint control compiled into the engine. A drop-in for Playwright & Puppeteer.

Free for one browser with GitHub. No card.