HTTP/2 Fingerprinting

HTTP/2 fingerprinting identifies a client by how it sets up and drives the connection rather than by what it puts in the headers. Four inputs are usually combined into one signature: the parameters in the client's opening SETTINGS frame, the increment on its first connection-level WINDOW_UPDATE, the stream priority tree it declares, and the order in which it emits the request pseudo-headers. The combined form is commonly called the Akamai fingerprint, after the notation that popularized it.

The values differ between stacks because the specification leaves them open. RFC 9113 defines six SETTINGS parameters with defaults (HEADER_TABLE_SIZE 4,096 octets, ENABLE_PUSH 1, INITIAL_WINDOW_SIZE 65,535 octets, MAX_FRAME_SIZE 16,384 octets, and no initial limit on MAX_CONCURRENT_STREAMS or MAX_HEADER_LIST_SIZE; read on rfc-editor.org 2026-07-27), and a client may override any subset, in any order, or none. Pseudo-headers work the same way. The spec requires that they precede regular field lines but sets no ordering among :method, :scheme, :authority and :path (RFC 9113 section 8.3, read on httpwg.org 2026-07-27). Every implementation therefore picks a sequence and keeps it. Browsers emit one; most client libraries emit another, and the difference is a single stable string. The HTTP/1.1 equivalent is header casing and order: field names are case-insensitive, so libraries canonicalize them (Go's net/http rewrites to Title-Case) and write them in an order no browser produces.

This is why a TLS impersonation fix often only half works. A client can replay a byte-perfect Chrome ClientHello and then announce a Go or Python HTTP/2 stack one frame later. The two checks are independent, they run at different layers, and passing one says nothing about the other. When JA3 or JA4 work moves a target from blocked to intermittently blocked, the HTTP/2 layer is the next place to look.

Capture your own traffic before guessing at values. The second practical consequence is that the fingerprint is not entirely yours to control. Any service that terminates TLS and re-originates HTTP/2 presents its own SETTINGS and pseudo-header order to the target. For managed products like Scrapfly, ZenRows, ScrapeNinja and Scrappey that is the product, and it is what you are paying for. It is a surprise inside a proxy tier you assumed was a plain CONNECT tunnel. Ask any vendor which of the two their endpoint does, because that answer decides whether your fingerprint work reaches the target at all.