JA4H, JA4T, and JA4L extend TLS fingerprinting to HTTP requests, TCP handshakes, and latency. Here's how each works and why mismatches matter.
TLS fingerprinting covers JA3 and JA4 — the fingerprint read from a single TLS ClientHello. But JA4 was never meant to stand alone. Its creator, FoxIO, publishes it as part of a wider family called JA4+, and most of that family fingerprints things that have nothing to do with TLS: the HTTP request itself, the TCP handshake underneath it, and even how long packets take to travel between client and server. Each layer is read independently, and — as you'll see below — the real power shows up when the layers disagree with each other.
Key Takeaways
- JA4+ is a suite, not one fingerprint. JA4 covers the TLS ClientHello; JA4H fingerprints the HTTP request, JA4T the TCP handshake, and JA4L the connection latency — each reading a different, independent layer of the same connection.
- The layers are orthogonal, and that's the point. A User-Agent and TLS fingerprint that say "Chrome on Windows," paired with a TCP fingerprint that says "Linux kernel," is a textbook proxy or anti-detect-browser tell — no single layer would catch it.
- JA4T reads the SYN packet, before any encryption. Window size, TCP option order, MSS, and window scale come from the OS network stack, so JA4T identifies the kernel, the same signal described in TCP/IP fingerprinting — JA4T just gives it a structured, sortable string.
- The format is deliberately human-readable. Unlike JA3's opaque MD5 hash, every JA4+ fingerprint is sectioned as
a_b_c, with a readable prefix you can partially decode by eye — and an analyst can match on just part of the string instead of the whole thing. - Licensing is split. JA4 itself is open-source (BSD 3-Clause), and FoxIO says it won't pursue patents on it. JA4H, JA4T, JA4L, and the rest of the "+" suite are patent-pending and released under the FoxIO License 1.1: fine for academic and internal business use, but selling them inside a product or hosted service requires an OEM license.
- None of this is visible to page JavaScript. JA4+ is computed by a server, a CDN, or a network appliance reading raw packets — a client-side tool like our fingerprint check cannot show you your own JA4H or JA4T, because your browser never sees the packets it just sent.
A Quick Recap: JA4 (TLS)
TLS fingerprinting is covered in depth elsewhere on this site, so here's the three-sentence version. Every HTTPS connection opens with a plaintext ClientHello listing cipher suites, extensions, and elliptic curves, in an order set by the client's TLS library rather than the user. JA4 sorts those values, strips GREASE noise, and hashes what's left into a fingerprint like t13d1517h2_8daaf6152771_cb7bf5808d99 — stable across sessions, readable in its prefix, and specific to the TLS library in use. Everything below this section reads a different layer of the same connection.
JA4H: Fingerprinting the HTTP Request
JA4H reads the actual HTTP request a client sends — not the body, but the request's shape. (On HTTPS, that's done by whoever terminates TLS: the server itself or a CDN in front of it.) According to FoxIO's JA4H specification, the fingerprint's readable prefix encodes the request method (the first two letters, lowercased — ge for GET, po for POST), the HTTP version (11 for HTTP/1.1, 20 for HTTP/2), whether a Cookie header is present (c or n), whether a Referer header is present (r or n), a two-digit count of headers (excluding Cookie and Referer), and the first four characters of the Accept-Language value (enus for en-US, or 0000 when the header is missing). That prefix is followed by short hashes of the header names in the order they were sent, of the cookie field names, and of the cookie names together with their values — the cookie-name hash tends to be the same for every visitor to a given site, while the name-and-value hash differs per user.
A real example from FoxIO's published fingerprint table: the IcedID malware dropper produces JA4H=ge11cn020000_9ed1ff1f7b03_cd8dafe26982. Decoded, that's a GET over HTTP/1.1 with a cookie, no referer, just two other headers, and no Accept-Language at all (the trailing 0000). Both details stand out. Real browsers typically send ten or more headers in a consistent, browser-specific order, and header order is exactly what the second segment hashes; FoxIO also points out that a missing Accept-Language is a strong sign the client isn't a human-driven browser. This is the same idea as the header-order signals discussed for HTTP/2 connections, applied generally rather than to one protocol version. One recent change is worth knowing if you compare fingerprints over time: an August 27, 2026 fix made FoxIO's Rust implementation exclude HTTP/2's own pseudo-headers (:method, :path, :scheme, :authority) from JA4H, since those are mandated by the protocol rather than chosen by the client — so HTTP/2 fingerprints that tool produced before and after the fix won't line up.
JA4T: Fingerprinting the TCP Handshake
JA4T reads the SYN packet that opens the TCP connection — the same layer covered in TCP/IP fingerprinting, just packaged into FoxIO's structured JA4 format instead of a p0f-style signature match. It composes four values from the TCP header: the advertised window size, the TCP options in the order the stack sent them (by their numeric kind — 2 for MSS, 1 for NOP padding, 3 for window scale, 4 for SACK-permitted, 8 for timestamps), the maximum segment size, and the window scale factor.
FoxIO's own example for a Windows 11 client is JA4T=64240_2-1-3-1-1-4_1460_8: a 64240-byte window, options in the order MSS–NOP–WindowScale–NOP–NOP–SACKPermitted, an MSS of 1460, and a window scale of 8. None of that depends on TLS, HTTP, or a User-Agent header — it's written by the operating system kernel before the browser has sent a single encrypted byte. Small details carry a lot of signal: FoxIO notes that Windows doesn't send the timestamp option (8) while Unix-like stacks do, so its absence from the example above is itself a Windows tell. The MSS field describes the network path as well as the OS. An MSS of 1460 is what standard Ethernet's 1500-byte MTU produces; a lower value such as 1380 points to the overhead of encryption or tunneling, and FoxIO describes a Unix-like fingerprint with an MSS of 1424 — 36 bytes of extra overhead — as possibly an unencrypted tunnel or proxy. On the tooling side, an August 27, 2026 fix aligned the numeric field formatting of FoxIO's Rust implementation with its Wireshark and Zeek implementations, which matters if you compare JA4T strings produced by different tools.
JA4L: Fingerprinting Latency
JA4L is the odd one out — it doesn't fingerprint a protocol field at all, but the timing of the handshake. Label the three packets of the TCP handshake A (SYN), B (SYN-ACK), and C (ACK), each timestamped wherever the observer sits. FoxIO defines JA4L-C as (C − B) / 2, an estimate of the one-way latency between the observer and the client, and JA4L-S as (B − A) / 2, the same estimate toward the server; both are in microseconds and paired with the TTL seen on that side's packets. A sensor right next to the server gets a meaningful JA4L-C and a near-zero JA4L-S, and vice versa. Because it only reads packet timing and IP headers, it works whether the traffic is encrypted or not.
Both numbers carry physical meaning. Nothing in a fiber travels faster than light — FoxIO works with roughly 0.128 miles (about 0.2 km) per microsecond, scaled by a propagation-delay factor for real-world routing — so a latency reading puts an upper bound on how far away the other end can physically be, which is why FoxIO pitches JA4L as a location measurement as much as a latency one. The TTL adds a second clue: operating systems start from different initial values (commonly 64 for Linux and macOS, 128 for Windows), so the observed TTL hints at both the hop count and the sender's OS family — one more field that can quietly contradict a User-Agent.
That makes JA4L a cross-check on location claims. If a connection's IP address geolocates to another continent but the handshake completes in a millisecond or two, something is off: the machine completing the handshake is physically close, whatever the IP database says. The reverse case is weaker evidence but still useful. A layer-3 VPN forwards the client's own handshake packets end to end, so the latency includes the hidden leg to the real user, and a reading far larger than the exit IP's location can explain hints that the client is further away than it appears. (Congestion can inflate latency too, which is why an impossibly low reading is the stronger signal.)
Rounding Out the Suite: JA4X, JA4SSH, and the Rest
A few more members are worth knowing by name even if they sit outside a browser-privacy audience's daily concern. JA4X fingerprints the X.509 certificates a TLS server (or client, in mutual-TLS setups) presents — but FoxIO is explicit that it captures how a certificate was generated, not the values inside it. Certificates minted by the same tooling therefore cluster together even when their names and keys differ, which is useful for tracking malware command-and-control (C2) infrastructure across campaigns. JA4SSH applies the same idea to SSH: it summarizes an encrypted session on a rolling basis (every 200 packets by default) from packet lengths, packet counts, and ACK patterns — enough to tell an interactive shell from a file transfer or a reverse shell without decrypting anything. The rest of the roster covers the server side and other protocols: JA4S (the TLS ServerHello response), JA4TS (the server's TCP SYN-ACK), JA4TScan (an active TCP scanner), and JA4D (DHCP). None of these touches a browser directly, but all follow the same design philosophy as JA4H/T/L: fingerprint what's structurally consistent about a client, independent of what it claims to be.
Why the Layers Disagreeing Is the Whole Point
Every fingerprint discussed on this site so far — canvas, WebGL, TLS — answers "what does this one signal say the client is?" JA4+'s real contribution is turning that into a cross-check: read several independent layers of the same connection, and see if they tell a consistent story.
A worked example: a scraping operation runs on a Linux server, sends a Windows Chrome User-Agent, and configures a TLS-impersonation library so its JA4 matches Chrome's exactly. That defeats a check that only inspects TLS. But the same server's kernel still writes its own TCP SYN packet — JA4T reads a Linux window size, option order, and MSS, none of which the impersonation library touches, because it operates above the OS network stack. A detection system that logs both fingerprints sees a request claiming Chrome on Windows arriving over a TCP handshake that is plainly Linux, and that contradiction is far harder to fix than either fingerprint alone — it requires controlling the impersonation library and the kernel's TCP stack and the HTTP client's header order, all at once, or the mismatch shows up in whichever layer got missed. This is the same compound-layer principle described in bot detection techniques and in how JA3 and JA4 stack with TCP/IP fingerprinting — inconsistency between observable layers is stronger evidence than any single anomaly.
Format Literacy: Why JA4+ Strings Are Readable
JA3's output was a single opaque MD5 hash — useful for exact matching, useless for a human glancing at a log line. FoxIO designed every JA4+ fingerprint around a deliberately readable a_b_c structure: a plaintext-decodable prefix (method, version, counts, flags) followed by one or more short hashes for the parts too granular to spell out. That readability isn't cosmetic. FoxIO's README states that the format "allows for hunting and detection utilizing just ab or ac or c only" — an analyst can, for example, match on the readable prefix plus one hash while ignoring the other.
It also has a practical payoff: because the format is specified rather than reverse-engineered, third parties can build compatible implementations. FoxIO's README lists native support in tools and services including Suricata, Arkime, ntopng, Cloudflare, AWS CloudFront and WAF, and Google Cloud Armor, while Wireshark and Zeek get it through plugins maintained in FoxIO's reference repository. Interoperability only holds if every implementation produces byte-identical strings, and that takes upkeep: on August 27, 2026, FoxIO merged two correctness fixes on the same day — JA4T's numeric fields in the Rust implementation realigned with the Wireshark and Zeek output, and JA4H's Rust fingerprint changed to exclude HTTP/2 pseudo-headers. It's a reminder that anything written about the exact layout of these fingerprints is only as current as the implementation version it describes.
Licensing: Why the Ecosystem Is Split
JA4 itself — the TLS client fingerprint — is released under the BSD 3-Clause license, the same terms JA3 shipped under, and FoxIO states it has no patent claims on it and won't pursue any. Every other member of the suite (JA4S, JA4H, JA4L, JA4X, JA4SSH, JA4T, and the rest) is patent-pending and licensed under the FoxIO License 1.1, which permits academic and internal business use but requires an OEM license to monetize the methods in a product or hosted service. That split is one reason some tools and services implement only JA4 and skip the rest of the suite — a licensing decision as much as a technical one.
What You Can Actually Do With This
Nothing in JA4H, JA4T, or JA4L is readable from page JavaScript. All three are computed from traffic as it arrives — TCP headers and handshake timing, plus the HTTP request once TLS is terminated — by whatever sits on the network path: a server, a CDN edge, or a monitoring appliance. That means our own fingerprint check tool, like every purely client-side fingerprinting demo, cannot show you your own JA4H or JA4T string: your browser has no view of the packets its operating system just sent on its behalf.
What you can do:
- See your TLS-layer JA4 live. The TLS fingerprinting page shows the TLS version, cipher suite, and — where available — the JA4 hash our edge observed for your current connection.
- Check the browser-side half of the cross-check. Our bot detection test looks for automation artifacts and headless-browser leaks inside the browser, and the fingerprint check shows the canvas, WebGL, and font signals a site can pair with network-layer fingerprints.
- Capture the rest yourself. Record your own traffic in Wireshark with FoxIO's JA4+ plugin to see JA4T and JA4L. JA4H needs the HTTP request in the clear, so it only appears for unencrypted HTTP unless you also have Wireshark decrypt TLS.
Where the Line Is With Other Posts on This Site
- TLS Fingerprinting Explained covers JA3/JA4 on the ClientHello itself — the layer this post assumes as background.
- TCP/IP Fingerprinting covers OS detection from IP/TCP headers generally, independent of the JA4T naming and format.
- HTTP/2 Fingerprinting covers the Akamai fingerprint — SETTINGS frames, pseudo-header order — a different HTTP-layer signature from JA4H.
- HTTP/3 and QUIC Fingerprinting covers QUIC's own transport-parameter fingerprint.
- Post-Quantum TLS Fingerprinting covers how ML-KEM key exchange reshapes the ClientHello's size and fields.
- How to Detect User-Agent Spoofing covers the same cross-layer-mismatch principle from the User-Agent side.
This post is specifically about the JA4+ family as a named suite, and how reading its layers together — not any one of them alone — is what makes it useful.
Frequently Asked Questions
Is JA4H the same as HTTP header-order fingerprinting?
Closely related, but not identical. JA4H is FoxIO's specific, standardized format for HTTP-request fingerprinting — a defined prefix plus hashed segments, published so multiple tools can produce and compare the same string. "HTTP header-order fingerprinting" is the more general technique it's built on; other tools and detection systems compute similar signals in their own, non-interoperable formats.
Does a VPN change my JA4T fingerprint?
Partly — and it depends on whether you're using a VPN or a proxy. A full-tunnel VPN (WireGuard, OpenVPN, IPsec) forwards the TCP packets your own operating system builds, so the window size, option order, and window scale in JA4T still describe your kernel. What usually changes is the MSS: the tunnel's encapsulation overhead pushes it below the 1460 of a plain Ethernet connection, and FoxIO cites values like 1380 as a sign of encryption or tunneling. A proxy works differently — it opens its own TCP connection to the site, so JA4T describes the proxy server's OS instead of yours. Either way, a JA4T that looks like a tunnel or a data-center Linux box, paired with a TLS fingerprint claiming an ordinary consumer browser, is one of the signals covered in how websites detect VPNs and proxies.
Can I look up my own JA4 fingerprints anywhere?
You can see your live JA4 (TLS) fingerprint on this site's TLS fingerprinting page, since that one is computed server-side from your connection and displayed back to you. JA4H, JA4T, and JA4L require a tool that reads raw packets or full HTTP requests — they aren't exposed through a simple client-side widget the way the TLS handshake fingerprint is.
Why would a company pay for a JA4+ license instead of just using JA3?
Because JA4+'s design solves real problems JA3 has — GREASE resistance, sortable and readable output, and coverage of layers JA3 never touched — that are valuable enough for security vendors to build products around. The FoxIO License 1.1 already allows academic and internal business use at no cost; the OEM license only comes into play when a company monetizes JA4+ methods in a product or hosted service. JA4 itself stays BSD-licensed, so a vendor that only needs the TLS-layer fingerprint doesn't need a license at all.
