Every value below was computed from the request that fetched this page, and is shown beside the exact string it was hashed from, so it can be checked by hand.
Requesting GET /api/v1/fingerprint
The request to GET /api/v1/fingerprint did not return a
result this page can use.
Reload the page to read the connection again, or request
/api/v1/fingerprint
directly to see what the server answers.
This service answers on TCP port 443 and, over QUIC, on UDP port 443, and it advertises HTTP/3 in Alt-Svc, so a browser that has been here before will usually upgrade to it by itself on a later visit. The two are different handshakes rather than one handshake over another transport: a QUIC ClientHello offers its own ciphers and extensions, carries quic_transport_parameters, and asks for h3 rather than h2, so the whole JA4 changes and not only its first character. This page arrived over QUIC. See the same client over TCP, which is this service on a name that never advertises HTTP/3. This page arrived over TCP, on the name that never advertises HTTP/3, so no upgrade will happen here: open the same page on fingerprints.ellio.tech to let your browser take one. This page arrived over TCP.
Read off the client SYN, the first packet of the connection, before any encryption exists.
This connection did not use TCP at all. It arrived over QUIC, which runs on UDP, so there was no SYN packet under it and nothing in this layer describes it. The card below says what that means.
MuonFP writes down four things the sender chose: the window it advertised, the TCP option kinds it listed and in what order, the largest segment it will accept, and its window scale. Nothing above TCP is involved, so it describes a client that speaks no TLS at all just as well as one that does.
No client SYN was captured, so there is no MuonFP value. Either the passive TCP sensor is off, or the connection reached this server through a proxy or load balancer that opened its own TCP session and hid the original one.
QUIC has no TCP handshake. This connection was carried in UDP datagrams, there was never a SYN packet, and a SYN is the whole of what MuonFP describes - so no MuonFP exists for this connection and none is reported. No sensor is off and nothing is in the way. The same browser over TCP produces one.
Reported by the API
An empty field means the option was absent, never that its value was zero.
This value does not match the layout above, so its characters cannot be tied to fields. It is shown exactly as it was observed.
| Field | Characters | Reading |
|---|---|---|
| Window size How many bytes the sender says it can accept at once, read from the first packet it sends. The field cannot go above 65,535. | ||
| Option order The TCP option kinds the sender listed during the handshake, in the order it listed them. | ||
| MSS The biggest piece of data the sender will accept in one segment, in bytes. 1,460 is a common value. | ||
| Window scale A multiplier for the window size: the real window is the advertised window times 2 to this power. The standard allows 0 to 14. |
raw the string the value was taken from
Read off the ClientHello, the first message the client sends once the TCP connection is up.
Over QUIC there is no TCP connection to wait for: the ClientHello travels in the CRYPTO frames of the client's first Initial packet instead. It is still a TLS 1.3 ClientHello and it is read the same way - which is why the JA4 below begins with q rather than t.
JA4 packs six fields into its first ten characters with no separator at all between them: transport, TLS version, whether a host was named, how many ciphers, how many extensions, and which protocol the client asked to speak next. Two truncated SHA-256 hashes follow, one over the sorted cipher list and one over the sorted extension list with the signature algorithms appended.
No ClientHello was captured, so there is no JA4 value. Either the TLS sensor is off, or the request arrived over cleartext HTTP or through a proxy that terminated the handshake before it reached this server.
Colour is what says where each of the first six fields starts.
This value does not match the layout above, so its characters cannot be tied to fields. It is shown exactly as it was observed.
| Field | Characters | Reading |
|---|---|---|
| Transport How the TLS handshake arrived: t means over a TCP connection (the way HTTPS starts), q means inside QUIC over UDP, d means DTLS, the UDP form of TLS. | ||
| TLS version The newest TLS version the client offered during TLS negotiation. This is the client's offer, not what the server chose. | ||
| SNI Whether the client asked for a site by name. Domain means it sent a hostname; IP means it connected straight to the address without naming one. | ||
| Cipher count How many encryption methods (cipher suites) the client offered. The field holds two digits, so 99 means 99 or more. | ||
| Extension count How many extensions the client's opening message carried. 99 means 99 or more. | ||
| ALPN The protocol the client asked to speak next, shortened to two characters: h2 is HTTP/2, h1 is HTTP/1.1, 00 means it named none. | ||
| Cipher hash (b) A SHA-256 of the client's full cipher list, truncated to 12 characters. Two clients share it only if their lists match exactly. | ||
| Extension hash (c) A SHA-256 of the client's extension list, truncated to 12 characters. The server name and protocol offer are left out first, so the same client gets the same hash wherever it connects. |
ja4_r the lists behind the two hashes, written out
GREASE stays excluded from both lists, and the extension list keeps SNI (0x0000) and ALPN (0x0010) that the sorted form removes.
ja4_o
ja4_ro
Many JA4 implementations in the wild do not follow the specification. If the value above is not the one you expected, one of the readings below probably produced yours: each is recomputed against this same ClientHello, so a match tells you which implementation a third-party value came from rather than leaving you to conclude the two describe different clients.
They diverge on two asymmetries. The a-section counts every non-GREASE extension, while the c-section hashes a sorted copy of that same list with SNI (0x0000) and ALPN (0x0010) removed; and the signature algorithms appended after that sorted list keep their wire order, unsorted. Each entry carries the sentence of the specification that settles it. One is not an error: stripping the ephemeral extensions is a deliberate convention, considered and declined by the specification's authors.
A reading marked "same for this client" produces the conformant value for this ClientHello, so a third-party value matching it could have come from either. Most readings separate only on particular client shapes: no ALPN, fewer than ten ciphers, GREASE signature algorithms, a resumed handshake.
JA3 predates JA4. It joins five comma-separated decimal fields - version, ciphers, extensions, supported groups, EC point formats - into one string and publishes the MD5 of that string.
No ClientHello was captured, so there is no JA3 value.
ja3_r the exact string the MD5 was taken from
The MD5 has no fields of its own, so these characters are cut from the raw string above.
This value does not match the layout above, so its characters cannot be tied to fields. It is shown exactly as it was observed.
| Field | Characters | Reading |
|---|---|---|
| TLS version The version in the client's own version field. JA3 always reads that field, so a TLS 1.3 client that negotiates through supported_versions still shows 771 here. | ||
| Cipher suites Every cipher suite the client offered, in decimal, in the order it sent them. GREASE placeholders are removed. | ||
| Extensions Every extension the client sent, in decimal, in wire order. A client that shuffles its extension order gets a new JA3 on every connection. Unlike JA4, the server name and the protocol offer stay in the list. | ||
| Supported groups The key exchange groups the client offered, in decimal, in wire order. | ||
| EC point formats The point formats the client will accept for elliptic curve keys. 0, uncompressed, is what almost every client sends. |
JA3N is JA3 with the extension list sorted ascending before hashing, and that sort is the entire difference between the two values. It cancels the extension shuffling that Chromium-based clients perform on every ClientHello, so one client keeps one value.
No ClientHello was captured, so there is no JA3N value.
ja3n
ja3n_r the exact string the MD5 was taken from
The MD5 has no fields of its own, so these characters are cut from the raw string above.
This value does not match the layout above, so its characters cannot be tied to fields. It is shown exactly as it was observed.
| Field | Characters | Reading |
|---|---|---|
| TLS version The version in the client's own version field, exactly as JA3 reads it. Normalisation does not touch this field. | ||
| Cipher suites Every cipher suite the client offered, in decimal, in the order it sent them. The cipher list is left in wire order here too. | ||
| Extensions Every extension the client sent, in decimal, sorted ascending. This is the one field JA3N changes, and it is what holds the value steady when a client shuffles its extension order. | ||
| Supported groups The key exchange groups the client offered, in decimal, in wire order. | ||
| EC point formats The point formats the client will accept for elliptic curve keys. 0, uncompressed, is what almost every client sends. |
Read off the request headers and, on an HTTP/2 connection, the client half of the connection preface that precedes them.
The Akamai fingerprint takes four things: the SETTINGS the client sent, the connection-level window it asked for, any standalone PRIORITY frames, and the order of the pseudo-headers in its first HEADERS frame.
This request did not use HTTP/2, so there is no connection preface to fingerprint. An HTTP/1.1 request has no SETTINGS frame, no WINDOW_UPDATE and no pseudo-headers.
This fingerprint is a sequence of HTTP/2 frames, and this request was HTTP/3. HTTP/3 sends its settings on a QUIC control stream rather than in an HTTP/2 preface, leaves flow control to QUIC instead of WINDOW_UPDATE, and dropped PRIORITY frames altogether - so there is no counterpart to compute and none is reported. This is not a failed read.
akamai_h2
Sections are separated by a vertical bar, and an empty section is still a section.
This value does not match the layout above, so its characters cannot be tied to fields. It is shown exactly as it was observed.
| Field | Characters | Reading |
|---|---|---|
| SETTINGS The parameters in the client's first SETTINGS frame, in the order it sent them, written as identifier:value. | ||
| WINDOW_UPDATE How many bytes the client added to the connection-level flow control window. 00 means it sent no WINDOW_UPDATE at all, which is not the same as adding zero. | ||
| PRIORITY The standalone PRIORITY frames the client sent, if any. 0 means it sent none. Priority carried inside a HEADERS frame is not counted here. | ||
| Pseudo-header order The order of the pseudo-headers in the first HEADERS frame, one letter each: m is :method, a is :authority, s is :scheme, p is :path. |
md5 the same four sections as a hash
JA4H packs the method, the HTTP version, whether a cookie and a referer were sent, how many header fields there were, and the first Accept-Language tag into twelve readable characters. Three truncated SHA-256 hashes follow: the header names in the order they were sent, the cookie names, and the cookie name=value pairs.
No request headers were captured, so there is no JA4H value.
Reported by the API
ja4h
Colour is what says where each of the first six fields starts; an underscore precedes each of the three hashes.
This value does not match the layout above, so its characters cannot be tied to fields. It is shown exactly as it was observed.
| Field | Characters | Reading |
|---|---|---|
| Method The request method, cut to its first two characters, so methods that share those two characters land on the same code. | ||
| HTTP version The HTTP version the request used, written without its dot: 11 is HTTP/1.1, 20 is HTTP/2. | ||
| Cookie present Whether the request carried a Cookie header. c means it did, n means it did not. | ||
| Referer present Whether the request carried a Referer header. r means it did, n means it did not. | ||
| Header count How many header fields the request carried. Cookie, Referer and the HTTP/2 and HTTP/3 pseudo-headers are left out of this count. | ||
| Accept-Language The first four characters of the first Accept-Language tag, hyphens removed and padded with zeros. 0000 means the request sent no Accept-Language header. | ||
| Header name hash (b) A SHA-256 of the header names in the order they were sent, truncated to 12 characters. JA4H never sorts this list: the order is what separates one client library from another. | ||
| Cookie name hash (c) A SHA-256 of the cookie names, sorted by byte value so uppercase names come first, truncated to 12 characters. | ||
| Cookie name=value hash (d) A SHA-256 of the cookie name=value pairs, sorted by cookie name, truncated to 12 characters. |
ja4h_r the header and cookie lists behind the three hashes
JA4H never sorts the header names, so only the two cookie sections change.
ja4h_o
ja4h_ro
Where network fingerprints hold, where they break, and what they are still worth once a client would rather not be recognised.
Talk
Until you press play, nothing on this page is requested from YouTube or from any other host; after it, YouTube sees a connection from you and can fingerprint it exactly as this page does.
Blog post
What each control catches that the other misses, why a TCP fingerprint outlives the address it arrived from, and how to run the two together on the same traffic.