JA3 / JA3S fingerprint
Compute the JA3 (ClientHello) or JA3S (ServerHello) TLS fingerprint from a raw captured TLS record. JA4 is not implemented. See the tool source for why. A matching fingerprint means two handshakes look alike, not that either endpoint is safe or malicious.
Runs on your device. The file is never uploaded.
JA3 / JA3S fingerprint reads one captured TLS record and prints the JA3 string beside its MD5, or JA3S when the record holds a ServerHello. The string joins version, cipher suites, extensions, supported groups and EC point formats with commas, dropping GREASE from all but the point formats. JA4 is absent: confirming its rules needs network access.
Questions
What is a JA3 fingerprint?
A short identifier for how a TLS client says hello. The tool reads a captured ClientHello and builds the JA3 string from its version, cipher suites, extension types, supported groups and EC point formats, then MD5s that string. For a ServerHello it builds JA3S instead, which is version, the chosen cipher, and extensions. Both the string and the hash are printed.
Is MD5 here a security problem?
No, because nothing is being protected. JA3 defines MD5 as its output function, so using anything stronger would produce a value that matches nothing else. The digest is a label for the shape of a handshake, not an integrity check, and the tool prints the full JA3 string beside it so you can see what was hashed.
Does a matching fingerprint mean the traffic is malicious?
No. It means two handshakes look alike. Different software using the same TLS library often shares a fingerprint, and a client can change its own. Treat the value as one signal to correlate, never as a verdict about either endpoint.
Why are some values missing from the string?
GREASE values are excluded from the cipher, extension and group lists, following the JA3 rules, so a client that randomises them still hashes to the same fingerprint. Point formats are not filtered. The TLS record parser on this site shows the same handshake with the GREASE entries left in and marked.
Can it do JA4?
No, deliberately. The tool source explains that its extension sorting and truncated SHA-256 rules were never confirmed against the specification, which needs network access, and that a fingerprint which merely looks plausible would be worse than none. The JA3 field ordering here was checked by hand against a real ClientHello decoded with openssl.
What if I give it the wrong bytes?
It stops and tells you what it saw: that the record is not a ClientHello or ServerHello, along with the content type and handshake type it found. Give it raw record bytes from a capture, starting at the record header. A length field pointing past the end of your bytes gives a truncated message naming the offset instead.