TLS Checker
See the TLS ClientHello your browser sends — JA3, JA4, TLS version, cipher, key exchange, platform and connection IP — or scan any domain or IP for its certificate, supported protocols and server stack. Free, no signup.
Every profile deserves its own network identity
Antybrowser gives each account an isolated browser profile with a matching fingerprint, proxy and locale. What this checker shows about your current browser, the desktop app controls per profile.
TLS checker: what your ClientHello says before the first byte
Before a website sees your IP, your cookies or a single HTTP header, your browser and the server perform a TLS handshake. The first message in that handshake — the ClientHello — lists the protocol versions, cipher suites, extensions and key-exchange groups the browser is willing to use. That list is remarkably stable per browser build, which is why anti-fraud systems compare it against the identity a profile claims.
This free TLS checker reads the handshake your browser just performed with our edge (JA3, JA4, TLS version, cipher, key exchange and HTTP version), shows the platform and connection IP the request claims, and can also scan any public domain or IP for its certificate and supported TLS versions. No signup, and the browser check stores nothing.
What the TLS handshake exposes
TLS negotiates a protocol version (today almost always TLS 1.3, sometimes TLS 1.2), a cipher suite, a key-exchange group and a set of extensions. Modern browsers also use ALPN to agree on HTTP/2 or HTTP/3 before the first request. The combination is a fingerprint: two browsers that offer different cipher lists or extension orders look different on the wire even when their user-agent strings are identical.
The checker reports the negotiated parameters from our edge, so what you see is what a real server received — not a JavaScript approximation. When the edge forwards viewer metadata, you also get the exact JA3 and JA4 hashes, the session handshake type and the order of your request headers.
JA3 and JA4 in plain English
JA3 hashes the TLS version, the ordered cipher-suite list and the ordered extension list into an MD5 digest. JA4 is the newer, more readable format: its prefix alone tells you the TLS version, how many cipher suites and extensions were offered, whether SNI was present and which ALPN protocol was chosen.
A JA3 or JA4 value is a signature, not a verdict. Chrome on Windows and Chrome on Linux send the same BoringSSL ClientHello for the same build, so a matching hash proves the same TLS stack and build — not the same operating system. TLS session resumption also changes the extension list (Chrome adds a pre-shared-key extension), so compare a fresh profile before treating a mismatch as spoofing.
The fingerprint is still useful: an anti-detect profile that claims to be Chrome but sends a Firefox NSS ClientHello, or a headless automation client with a Python TLS stack, is visible immediately. Use the fingerprint checker and user-agent checker alongside this page to compare the whole identity.
Does the TLS fingerprint reveal Windows or Linux?
Not by itself. Chrome, Edge, Brave and other Chromium browsers all use BoringSSL, and Firefox uses NSS on every desktop OS. The TLS library is shared across platforms, so the ClientHello is usually identical on Windows, macOS and Linux for the same browser version. The operating-system line on this page comes from User-Agent Client Hints (or the user-agent string when hints are unavailable), not from JA3/JA4.
The layer that does carry OS traits is the TCP/IP stack — TTL, window size, MSS and TCP options — which a TLS terminator such as a CDN cannot see. A Linux claim served through a Windows host still produces a Windows TCP stack; that is a network-level check, not something a browser JavaScript page can read.
What the page does show is coherence: if Client Hints say Linux while the UA string says Windows, the platform card and the findings flag the contradiction. That is the same comparison anti-fraud vendors run, and it is usually more actionable than the TLS hash alone.
Checking a server's TLS, certificate and stack
Switch to the Any host tab to scan a public domain or IP. The scanner performs a real handshake for each protocol version it can test, retrieves the certificate chain and reports the subject, issuer, validity window, SANs, SHA-256 fingerprint, signature algorithm, public-key type and chain depth. It also sends one HTTP HEAD request for the Server and X-Powered-By headers, which gives a cautious platform hint (IIS suggests Windows; nginx or Apache suggests Linux/Unix, but both run on other systems too).
Use it to check a proxy exit, a customer site or your own deployment: an expiring certificate, a hostname mismatch, a missing TLS 1.3, a CBC cipher or a certificate that no public CA signed all show up as findings. The report is stored for 30 days behind a share link; the target and certificate are public information, and the visitor's IP is never part of the report.
Why protocol support is tested in the browser
The TLS version on the handshake card is the version your browser and our edge agreed on. That is not the same as support: a browser that also supports TLS 1.2 will happily negotiate 1.3 and never reveal the older fallback. The protocol card probes version-pinned test hosts from your browser, so you can see which versions it can actually negotiate — and confirm that TLS 1.0 and 1.1 are refused by a current browser.
One limitation is honest: the probe is a reachability test, so a network filter that blocks the test host also reads as unsupported. The edge readout and the certificate scan remain authoritative for the connection and the server respectively.
A TLS checker answers a narrow but important question: what does the transport layer say about this browser or this server? Use it with the fingerprint checker, the IP checker and the HTTP header checker to see the full picture. The free tools show what the web sees; Antybrowser gives every account an isolated profile with a matching fingerprint, proxy and network identity.
Frequently asked questions
What is a TLS fingerprint?
The TLS ClientHello is the first message your browser sends to a server. It lists the protocol versions, cipher suites, extensions and key-exchange groups the browser supports. JA3 and JA4 hash that list into a short signature that anti-fraud systems can compare across sessions.
Does the TLS fingerprint reveal Windows or Linux?
No. Chromium browsers use BoringSSL on every desktop OS, and Firefox uses NSS, so the same browser build sends the same ClientHello on Windows, macOS and Linux. The operating-system line on this page comes from User-Agent Client Hints or the UA string, not from JA3/JA4. A TCP/IP stack fingerprint is a different layer and is not visible to a website behind a CDN.
Why are JA3 and JA4 empty sometimes?
TLS terminates at the CDN edge, not in the Next.js app, so the app can only report the ClientHello when CloudFront forwards its viewer headers. Local development and a deployment without the /api/tls-fingerprint* cache behaviour show the platform, IP and protocol cards only. The host scan is unaffected.
What does the Any host scan do?
It opens a real TLS connection to a public domain or IP on port 443 for each protocol version, retrieves the certificate chain and sends one HTTP HEAD request. You get the supported versions, the negotiated cipher, the certificate's subject, issuer, validity, SANs and fingerprint, and a server-platform hint from the Server header.
Is the TLS checker free and private?
Yes. The browser check is free, needs no account and stores nothing. The host scan stores a 30-day report behind a share link so the result can be reopened; the report contains the target, certificate and TLS facts, never page content, cookies or the visitor's IP. Raw IPs are not stored — the daily scan quota uses a salted hash.
Why do TLS 1.0 and 1.1 show as unknown?
The host scanner runs on Node 24 with OpenSSL 3, which can no longer negotiate TLS 1.0 or 1.1. A failed probe therefore means not testable, not disabled. Modern browsers have also disabled those versions, so the browser-side protocol probes normally show them as not offered.
What is the difference between JA3 and JA4?
JA3 is an MD5 over the TLS version, cipher list and extension list. JA4 is a newer format with a readable prefix (protocol version, cipher and extension counts, SNI flag, ALPN) plus hashes. JA4 is easier to compare and has separate variants for ordered and randomized extension lists; this page shows the value the edge reports.
Can I use this to verify an anti-detect profile?
Yes — as one layer of the check. Run it inside the profile you are testing and compare the TLS stack, platform and timezone with the profile's claimed identity. Then use the fingerprint checker, user-agent checker and IP checker for the rest. A matching JA4 proves the TLS stack matches the claimed browser; it does not prove the OS or the proxy exit match.