What a JA3 Fingerprint Lookup Reads in Your Connection
A JA3 fingerprint lookup takes the TLS ClientHello your browser sends when it opens an HTTPS connection, pulls five fields out of it, and shows you the MD5 hash of that list. Most tools also print the raw string behind the hash, plus the cipher suites, extensions and curves your client offered. That is the whole output: a description of the TLS software making the connection, not of the person using it.
📌 TL;DR Executive Summary
- Core Takeaway: A JA3 hash is an MD5 of five ClientHello fields — TLS version, cipher suites, extensions, elliptic curves and EC point formats. The raw string is the readable part; the 32-character hash cannot be decoded on its own.
- Key Risk/Challenge: Chromium has shuffled TLS extension order since early 2023, so the same Chrome often produces a different JA3 on every connection. JA3 also misses QUIC traffic and is implemented inconsistently across tools.
- Recommended Solution: Capture the raw string, repeat the lookup across several connections, and cross-check with a JA4 lookup before drawing any conclusion about a client.
The Lookup Result, Field by Field
Open a lookup page in your browser and you get a small set of values, all derived from one message your client sent before any HTTP request existed: the 32-character hash, the raw JA3 string, the negotiated TLS version, the cipher suite list, the extension list and the elliptic curves. Nothing in that result comes from cookies, headers or JavaScript.
The raw string is the readable half. Here is the example that appears in most JA3 documentation:
771,4865-4866-4867,0-23-65281,29-23-24,0
Five groups, commas between them, dashes inside each one. The numbers are IANA registry code points rather than vendor values, which is why the string is comparable across clients and why you can pull it apart without the original tool.
| Field | Value in the example | What it tells you |
|---|---|---|
| TLS version | 771 | The version value written into the ClientHello; 771 (0x0303) is TLS 1.2 in the registry |
| Cipher suites | 4865-4866-4867 | Which cipher suites were offered, in the client’s own preference order |
| Extensions | 0-23-65281 | Which TLS extensions were sent, and the order they went out in |
| Elliptic curves | 29-23-24 | Which key-exchange groups the client supports |
| EC point formats | 0 | The point format offered for elliptic-curve operations; 0 is uncompressed |
Those code points are legible if you know the registry. In the extension group, 0 is server_name and 65281 is renegotiation_info. In the curve group, 29 is x25519, 23 is secp256r1 and 24 is secp384r1. Watch for the overlap: 23 is secp256r1 among curves and extended_master_secret among extensions, so always read a number inside its own group. Read left to right and a current desktop browser looks long and generic, while a command-line HTTP client, a scraper library or an embedded device tends to offer a short, distinctive list. The hash alone tells you nothing you can interpret — only the raw string breaks back into fields.
How the JA3 Hash Is Built Under the Hood
Every HTTPS connection follows the same opening sequence. The client opens a TCP connection, sends a ClientHello, receives a ServerHello and certificate, derives session keys, and only then sends the encrypted request carrying the User-Agent, cookies and headers. JA3 is computed at the second step, before a single byte of HTTP exists.
The five ClientHello fields are converted to decimal, joined with commas between groups and dashes inside them, then hashed with MD5 into 32 hexadecimal characters. One detail trips people up: the version field records what the client wrote into the ClientHello, which is not always the version finally agreed — TLS 1.3 negotiation happens inside an extension. Good lookup tools show the negotiated version separately, so the two numbers can legitimately disagree.
Salesforce researchers John Althouse, Jeff Atkinson and Josh Atkins published the method in 2017. It spread because it was cheap to compute and needed no JavaScript, no cookies and no cooperation from the client. Because the input comes from the TLS library compiled into the client, the result describes the software build rather than the network — an IP change or a VPN tunnel does not move it. Our guide on how JA3 fingerprinting works walks the handshake in more detail.
Why Your JA3 Hash Keeps Changing
The most common question about a JA3 lookup is why the result differs on every refresh. In early 2023 Google made Chromium-based browsers shuffle the order of TLS extensions, so the same Chrome install produces a different JA3 on almost every connection. Cloudflare’s analysis names this as a core reason JA3 became unreliable for identification.
Extension order is not the only weakness. Tools and databases implement JA3 inconsistently, so the same client can be labelled differently depending on where you look it up. The fingerprint covers the TLS ClientHello only, so HTTP/3 traffic sent over QUIC is not described at all. Resumed TLS sessions are not recalculated, and plain HTTP has no fingerprint because there is no handshake to inspect.
JA3 vs JA4: What a Modern Lookup Shows
FoxIO launched JA4 in September 2023 as the successor, and Cloudflare now documents both. JA4 splits the result into a human-readable header and two truncated SHA-256 hashes of the sorted cipher and extension lists, with GREASE values removed. Sorting is the whole point: shuffle the extension order as much as you like and the sorted list does not move, so the fingerprint stays stable between connections.
The header encodes what you would otherwise decode by hand. In t13d1516h2, t means TCP (a QUIC connection shows q), 13 is TLS 1.3, d means the SNI carried a domain name, 15 is the cipher count, 16 the extension count and h2 the ALPN protocol. A complete example reads t13d1516h2_8daaf6152771_000000000000.
| Aspect | JA3 | JA4 |
|---|---|---|
| Published | 2017, Salesforce researchers | September 2023, FoxIO |
| Construction | Five fields concatenated, then MD5 | Readable header plus two sorted, truncated SHA-256 hashes |
| Readable by eye | Raw string only; the hash is opaque | Header reads without a decoder |
| Stability | Breaks when extension order is shuffled | Holds because lists are sorted before hashing |
| QUIC coverage | None | Transport field separates TCP from QUIC |
| Licensing | Open method | JA4 under BSD 3-Clause; JA4+ family under the FoxIO Licence |
The wider JA4+ family adds JA4H for HTTP clients, JA4T for TCP characteristics and JA4S for server responses. Check licensing before you build anything commercial on top. JA4 itself is BSD 3-Clause, the other family members fall under the FoxIO Licence with commercial arrangements required, and FoxIO states the technology is patent pending, with terms last updated 1 September 2025 that restrict reproduction and reverse engineering. Our JA3 vs JA4 comparison covers the remaining field-level differences.
Who the Fingerprint Actually Affects
Bot management platforms treat JA3 and JA4 as one input among many. Cloudflare exposes both, plus ja4Signals, in bot analytics, security events and logs, and lets customers write rules against them — its fingerprint documentation shows where each value surfaces. The direction of travel matters more than any single hash: modern WAFs correlate the TLS fingerprint with User-Agent rarity and protocol consistency instead of blocking on a static value.
Mobile apps are the clearest case where the signal is strong. Traffic from one embedded TLS library often produces the same JA3 across devices and users, so a WAF can recognise the app itself by its handshake. That still says nothing about the individual behind it. A fingerprint identifies software, not a person: every up-to-date Chrome on the same platform shows essentially the same JA4.
Two shifts shape the rest of the picture. More than 90% of web traffic now runs over TLS, which erodes the value of IP-based indicators, and Encrypted Client Hello encrypts sensitive ClientHello fields including SNI, removing metadata that defenders used to read. Historic malware tables remain useful background — sslbl.abuse.ch lists JA3 hashes tied to families such as Dridex and TrickBot, one Dridex entry showing 315,517 hits since 2018-12-17 — but read them as history, not current threat intelligence.
Most people running lookups are not security researchers. They are QA engineers testing as different users, support teams reproducing regional behaviour, and agencies verifying that the accounts they manage behave consistently from the environments they built.
A Practical JA3 Fingerprint Lookup Checklist
Follow these in order and you skip most of the confusion these tools create.
- Test the exact client you care about. Run the lookup from the same profile, device and proxy you are investigating, not from a different browser on the same machine.
- Capture the raw string first. Copy the comma-and-dash string before the hash, and note the negotiated TLS version and ALPN values shown beside it.
- Repeat five to ten times. If the hash changes while the field lists match, you are watching extension shuffling, not a fault.
- Change one variable at a time. Once with the proxy off, once on, once from another network. The fingerprint should follow the client, not the route.
- Compare against a reference. Take the same lookup from a clean browser of the same version on the same operating system. If the two differ, something in your setup is altering the handshake.
- Cross-check with JA4. When JA3 rotates on every request, JA4 gives you a value you can compare across sessions.
- Check protocol consistency. A client claiming a current Chrome in its User-Agent while offering a short, library-style cipher and extension list is the pattern worth investigating.
- Record the environment. Operating system, browser build, proxy type and lookup tool in the same note. Without that context the numbers are not comparable later.
Common Mistakes When Reading a Lookup
- Treating one lookup as a baseline. A single hash describes one connection. Capture a set before you call anything “normal”.
- Blurring the TLS layer with the JavaScript layer. Canvas, WebGL, audio and font values are collected after the page loads and are a separate signal entirely. Start with what a browser fingerprint is if the two are running together in your notes.
- Assuming an intercepting proxy is transparent. A proxy that terminates and re-originates TLS presents its own handshake, so the fingerprint you see belongs to the proxy, not the browser behind it.
- Calling a short extension list broken. Lightweight clients legitimately send few extensions. Short is not the same as faulty.
- Trying to decode a bare hash. There is nothing inside it to read. Only the raw string decomposes into fields.
- Reading old threat tables as current. Malware-associated JA3 lists are historical. A match is not evidence about today’s traffic.
- Forgetting the blind spots. Plain HTTP has no fingerprint, resumed sessions are not recalculated, and HTTP/3 may not appear in a JA3 view at all.
How Send.win Helps With Ja3 Fingerprint Lookup
Send.win is a browser profile manager for professionals and teams: every account gets its own isolated browser profile.
- Isolated profiles – separate cookies, storage and sessions per profile
- Fingerprint protection – each profile keeps its own consistent browser fingerprint, so profiles never share one browser identity
- Desktop app + cloud browser – native app for Windows, macOS and Linux, or run profiles in the cloud with no install
- Residential proxies included – on Pro and Team, with timezone and locale matched to the proxy
- Team sharing – share a signed-in profile with a teammate without sharing the password
Try the free cloud demo — no install — or download the desktop app. Paid plans start at $19/month, and your first card purchase is covered by a 7-day money-back guarantee (see pricing).
Where Profile Isolation Fits in the Workflow
A TLS lookup answers one question about one connection. Work across client accounts, storefronts or test cases and the harder question is which environment a connection came from: which cookies, which logins, which proxy, which fingerprint settings. That layer sits above the handshake, and it is where a browser profile manager earns its place.
Send.win gives every profile its own cookies, storage, sessions, fingerprint settings and proxy. The protection it applies — canvas, WebGL, audio, fonts, hardware — lives in the browser engine at the JavaScript layer, one level above what JA3 describes. It does not rewrite your ClientHello, and a JA3 or JA4 lookup run from a Sendwin Browser profile will show the TLS fingerprint of the Chromium build inside the app. What it does keep aligned is everything downstream: timezone, locale, WebRTC and geolocation follow the proxy’s exit IP, and a login in one profile stays invisible to the next.
Sendwin Browser is a desktop app for Windows, macOS and Linux. The cloud browser runs profiles on Send.win’s server in Helsinki, Finland, from any device with nothing to install, and the free demo gives you a three-minute preview without signing up, or ten minutes a day with a free account. Sharing a profile with a paid teammate opens it already signed in, so no password changes hands. There is no API, SDK or headless mode on any plan, so nothing here is meant to be scripted. Our guide to browser fingerprinting and isolation shows how the layers stack. Use it only with accounts you own or are authorised to manage.
🏆 Send.win Verdict
A JA3 lookup tells you what your TLS stack looks like — it will not tell you why a profile behaves inconsistently across a client’s environments. Send.win works on the layer above: separate profiles with their own cookies, storage and fingerprint settings, proxies whose exit IP drives timezone, locale and geolocation, and profile sharing that skips the password hand-off. It does not touch your TLS handshake, and it does not need to; keeping the upper layers coherent removes most of the false mismatches people end up chasing.
See Send.win plans — Pro from $19/mo ($83.88/yr billed annually) with residential proxies included, Team from $49/mo, or start in the free cloud demo with 10 minutes a day.
Frequently Asked Questions
What does a JA3 fingerprint lookup show me?
It shows the MD5 hash of five TLS ClientHello fields, plus the raw string those fields came from: TLS version, cipher suites, extensions, elliptic curves and EC point formats. Good tools also display the negotiated version and ALPN. All of it describes the TLS software making the connection.
Why does my JA3 hash change every time I run the lookup?
Chromium has shuffled TLS extension order since early 2023, so the same browser builds a different concatenated string — and therefore a different MD5 — on almost every connection. That is expected behaviour, not a misconfiguration. Compare the field lists rather than the hashes, or use JA4, which sorts the lists before hashing.
Can a website see my JA3 fingerprint through a VPN?
Yes. The fingerprint comes from your local TLS library, so it survives an IP change and a VPN tunnel. The destination server receives the same ClientHello it would have seen without the VPN, which is why JA3 became popular once IP-based indicators lost value.
Does a proxy change my TLS fingerprint?
Normally no. HTTP CONNECT and SOCKS5 proxies tunnel the encrypted stream, so the handshake still originates in your browser and the fingerprint is unchanged. A proxy that intercepts and re-originates TLS terminates the handshake itself and presents its own fingerprint instead.
What causes a JA3 mismatch with my browser?
Usually extension shuffling, a different build of the same browser, or a client library sending the handshake instead of the browser. Check the negotiated version and ALPN first, then repeat the lookup several times. If the field lists differ consistently, something between the browser and the network is changing the handshake.
What is the difference between JA3 and JA4?
JA3 is a single MD5 of five concatenated fields, published in 2017. JA4, released by FoxIO in September 2023, produces a readable header plus two sorted, truncated SHA-256 hashes, removes GREASE, and separates TCP from QUIC. In practice JA4 stays stable where JA3 rotates.
Is JA3 still used for bot detection in 2026?
Yes, but rarely on its own. Cloudflare still surfaces JA3 and JA4 in bot analytics, security events and logs, and customers can write rules against them. The pattern across the industry is to correlate the fingerprint with User-Agent rarity and protocol consistency rather than block on a static hash.
Can I use JA4 and JA4+ fingerprints commercially?
Check the licence first. JA4 itself is available under the BSD 3-Clause licence, while other members of the JA4+ family such as JA4H and JA4S fall under the FoxIO Licence with commercial monetisation arrangements required. FoxIO also states that the technology is patent pending.