Mercury vs JA4 vs JA3 Fingerprinting

Back to learning

Mercury NPF, JA4, and JA3 can all describe features of a TLS ClientHello, but they make different tradeoffs. JA3 produces a compact exact-match identifier. JA4 produces a structured, partly readable identifier designed to be stable when ClientHello lists are reordered. NPF can retain a richer, versioned tree and also offers a compact hash nickname.

None of them identifies an application, device, or person with certainty. The useful question is not “which fingerprint wins?” It is “what representation and supporting context does this job require?”

The practical comparison

Read the canonical details in what is JA3 fingerprinting?, what is JA4 fingerprinting?, and Cisco's draft NPF specification.

When JA3 is useful

JA3 remains common in historical datasets, rules, and incident reports. Its fixed MD5 value is easy to index and compare. That compatibility can matter more than adopting a newer format immediately.

Its limitations are equally clear. A hash hides the source fields, exact matching is brittle when ordered features change, and a shared TLS stack can create collisions at the meaning level even when the hash itself has not collided. Keep the pre-hash string when investigation and migration matter.

When JA4 is useful

JA4 is a good fit for compact telemetry, grouping, and rules that benefit from a more readable prefix and canonical sorting. Components can also be used separately when an analyst wants a broader cohort than the complete value.

JA4 is the TLS-client method. JA4+ is the name of a wider family that includes other protocol and direction-specific methods; it is not simply “JA4 with more server fields.” Cloudflare's “JA4 Signals” are behavioural aggregates around JA4, not another name for the JA4 format.

Normalisation improves stability, but it deliberately discards variation. Different clients can still share a JA4, and an active client can imitate the fields from another implementation.

When Mercury NPF is useful

NPF suits investigations and research where retained structure, explicit rule versions, and multiple protocol formats are valuable. An operator can inspect the selected bytes, see which parts were sorted, and retain a full representation for later comparison. The optional hash makes indexing easier without redefining the underlying fingerprint.

That richness costs storage and operational complexity. Systems must retain the format version, agree on matching rules, and handle longer values. Mercury's optional process analysis also needs a suitable, current knowledge base. It should not be compared with JA4 as though classifier output were part of the NPF string. See destination context and TLS attribution.

What all three miss

All three observe the handshake available at one capture point. A reverse proxy or TLS terminator can replace the visible client handshake on the next network leg. Browser and library updates cause drift. Shared stacks cause different software to look alike. Packet loss can prevent extraction, and deliberate mimicry can defeat naive attribution.

For threat hunting, retain raw context and review matches. For rate limits or blocking, combine a fingerprint with behaviour, route, account, network, and time-window evidence. A fingerprint is strongest as a cohort signal whose provenance can be checked later.

For the representation itself, read inside a Mercury NPF fingerprint. For the familiar portable formats, JA3 vs JA4 gives the narrower comparison.