the TLS fingerprint this browser presents to a server
Check id tls-fingerprint-readout
What an ordinary browser yields
Contextual only: this is your TLS fingerprint as a server sees it. There is no right answer, and none is asserted.
What a detector infers
This row reports rather than judges, and the reason it exists is that it is the only place on this page where the browser is described by something other than itself. JA4 condenses the ClientHello into a readable shape: the transport and TLS version, whether SNI was sent, how many ciphers and extensions were offered, the first ALPN protocol, and two hashes over the sorted cipher and extension lists. JA3 is the older form — an MD5 over the same material in wire order — and it is shown alongside because it is what most published research and most vendor documentation still quotes. GREASE is worth watching: Chrome injects reserved values into its cipher and extension lists on purpose, so their presence or absence says something about the stack that no user agent string can. What this row will never do is name your browser from its JA4. That requires a corpus of known fingerprints, and a corpus goes stale — Chrome's ClientHello changes between releases, and a table that is right today starts accusing honest browsers a few versions later. This audit made exactly that mistake once with a table of V8 heap sizes, and the lesson generalises: a check should go quiet when it meets something it does not recognise, never go wrong. So the fingerprint is shown, explained, and left for you to interpret — while the scored claim next to it is the one that needs no table at all.
How to resolve it
Nothing to fix. If you are presenting a browser identity, note that this fingerprint is decided by the TLS library your client links against and is entirely independent of the user agent string, navigator, or anything else JavaScript can set — the two are trivial to make disagree, and a server compares them for free.
Other checks in TLS & the network layer
- the TLS fingerprint is the same on two separate connections
ja4-stable-across-connectionsEverything else on this page reads the browser through JavaScript. - TLS cipher list matches the claimed engine
tls-cipher-suite-vs-engineYour browser announces which engine it is twice, through channels that cannot reach each other. navigator.userAgent is a string any page can… - TLS identity matches the browser
tls-browser-identityJA4 repeatability proves stability, not that the profile matches the claimed browser. - HTTP/2 settings and order
http2-fingerprint-readoutHTTP/2 SETTINGS and pseudo-header order are emitted below JavaScript. - HTTP/3 / QUIC transport
http3-quic-readoutQUIC versions and transport parameters form an independent fingerprint. - IP network classification
network-reputation-readoutASN, network class, and proxy/VPN/Tor indicators describe the route, not the browser, and are never standalone verdicts. - DNS resolver path
dns-path-readoutResolver identity requires an authoritative DNS canary; page JavaScript cannot inspect it.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on TLS & the network layer checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in TLS & the network layer — the family tls-fingerprint-readout belongs to.