What the Akamai HTTP/2 Fingerprint Actually Captures
The Akamai HTTP 2 fingerprint is a short text string that summarises the first frames a client sends when it opens an HTTP/2 connection: its SETTINGS values, a WINDOW_UPDATE increment, any PRIORITY frames, and the order of its pseudo-headers. Servers record it before a single byte of page content or JavaScript arrives, then compare it with your User-Agent and TLS handshake to check that all three describe the same browser.
📌 TL;DR Executive Summary
- Core Takeaway: The string has four pipe-separated fields — SETTINGS pairs, a connection WINDOW_UPDATE increment, PRIORITY tuples, and pseudo-header order letters (m, a, s, p). Every shipping browser emits a recognisable combination.
- Key Risk/Challenge: A Chrome User-Agent on top of a Python HTTP client sending its library defaults (header table 4096, 100 streams, window 65535) is a mismatch a server can see before the page renders.
- Recommended Solution: Measure your own string with an echo service, keep TLS, HTTP/2 framing and headers coming from one client, and run each identity in an isolated browser profile so the layers stay internally consistent.
Akamai published the format in its paper “Passive Fingerprinting of HTTP/2 Clients” at Black Hat Europe in 2017. It still reads cleanly today because the protocol barely moved: RFC 7540 and its 2022 revision RFC 9113 kept the six core SETTINGS identifiers. What changes is the values each browser build sends, so treat published strings as illustrations rather than constants.
How the Fingerprint Is Built, Frame by Frame
An HTTP/2 connection opens in a fixed order, and the Akamai HTTP 2 fingerprint summarises that order. The frames sit above TLS, so an edge server reads them in the first milliseconds without decrypting page content or executing anything.
Step 1: the 24-byte connection preface
Every client sends the same fixed 24-byte magic string before any frame: PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. It identifies nothing on its own, but it marks the exact byte where the interesting frames begin — which is what makes passive fingerprinting possible.
Step 2: the SETTINGS frame carries most of the signal
The client follows the preface with a SETTINGS frame. It can be empty in theory and never is in practice. Both which identifiers a client includes and the order it puts them in are part of the fingerprint, so two clients sending identical values in a different sequence already look different.
| ID | Identifier | Spec default | What it controls |
|---|---|---|---|
| 0x1 | HEADER_TABLE_SIZE | 4,096 | HPACK header compression table size |
| 0x2 | ENABLE_PUSH | — | Whether the server may push resources |
| 0x3 | MAX_CONCURRENT_STREAMS | not fixed | Streams the client will accept at once |
| 0x4 | INITIAL_WINDOW_SIZE | 65,535 | Per-stream flow-control window in bytes |
| 0x5 | MAX_FRAME_SIZE | 16,384 | Largest frame payload the client accepts |
| 0x6 | MAX_HEADER_LIST_SIZE | not fixed | Header list size the client will accept |
| 0x8 | ENABLE_CONNECT_PROTOCOL | — | RFC 8441 extended CONNECT, WebSockets over HTTP/2 |
| 0x9 | NO_RFC7540_PRIORITIES | — | Declares RFC 9218 priorities instead of the old tree |
Identifiers 0x8 and 0x9 are extensions, not part of the original six. They turn up in newer clients and are a fast way to date a build. If you see a field you cannot place, check extension IDs before assuming the client is exotic.
Step 3: WINDOW_UPDATE splits clients into three groups
HTTP/2 flow control opens every stream and the connection at a 65,535-byte window (2^16 − 1). Most browsers raise the connection window immediately with a WINDOW_UPDATE on stream 0, and that increment becomes the second field. Three populations show up: Chrome-family clients near 15.6 million, Firefox near 12.5 million, and clients that never raise the window at all — a 0, which is what most libraries emit.
Step 4: PRIORITY frames and pseudo-header order
The third field counts PRIORITY frames sent before the first HEADERS frame, usually 0 today. The fourth is a letter sequence for the pseudo-header order: m for :method, a for :authority, s for :scheme, p for :path. Chrome sends m,a,s,p, Firefox m,p,a,s and Safari m,s,p,a. It is the field you can read by eye fastest.
Priority handling is mid-transition. RFC 9113 deprecated the HTTP/2 priority tree, and RFC 9218 Extensible Priorities (June 2022) replaced it with a Priority header plus frames for HTTP/2 and HTTP/3. Some browsers still emit PRIORITY frames anyway, which is why the third field has not vanished from observed strings.
Chrome, Firefox and Safari Side by Side
These three strings are the reference points most write-ups quote. A weekly re-measurement project called fingerprint-db confirmed the Chromium one in October 2026 on Chromium 156, but treat every digit as version-dependent.
| Client | Akamai HTTP/2 fingerprint | What stands out |
|---|---|---|
| Chrome / Chromium | 1:65536;2:0;4:6291456;6:262144|15663105|0|m,a,s,p |
Sends 0x6 but skips 0x3 and 0x5; huge INITIAL_WINDOW_SIZE |
| Firefox | 1:65536;2:0;4:131072;5:16384|12517377|0|m,p,a,s |
Sends MAX_FRAME_SIZE 16384; :path before :authority |
| Safari | 2:0;3:100;4:2097152;9:1|10420225|0|m,s,p,a |
No HEADER_TABLE_SIZE at all; sends extension 0x9 |
The clearest gap is INITIAL_WINDOW_SIZE: Chrome declares 6,291,456 and Firefox 131,072 — a 48-fold difference in a single field. Safari’s omission of HEADER_TABLE_SIZE matters just as much, because a recipe that copies only Chrome’s window values still leaves the settings list short of what Chrome sends.
HTTP/2 Fingerprints vs JA3, JA4 and Cloudflare’s Checks
JA3 and JA4 summarise the TLS ClientHello — cipher suites, extensions, curves, and in JA4 also ALPN. The Akamai HTTP/2 fingerprint describes what happens after the handshake completes. They are different layers of one conversation, and bot management compares them directly.
That comparison got harder in January 2023, when Chrome 110 randomised TLS extension order and broke JA3’s assumption of a stable sequence. JA4 replaced order with a sorted count, so modern Chrome, Edge and Brave share the prefix t13d1516h2, Firefox reads t13d1715h2 and Safari t13d2014h2. The trailing h2 is the ALPN protocol, and it is the link between the two layers: one string claims HTTP/2, the other shows who is speaking it. Our TLS fingerprinting explained walkthrough covers the ClientHello half in order.
The practical rule: a perfect TLS fingerprint paired with the wrong HTTP/2 SETTINGS draws more attention than both being slightly unusual but mutually consistent. The stack is evaluated bottom-up — TCP/IP, TLS, HTTP/2 framing, header order and values, Client Hints, then behaviour — and the first four layers are decided before your page loads.
Who Runs Into HTTP/2 Fingerprint Mismatches
Most people who hit this are not running scrapers. They are QA engineers testing as different users, support agents reproducing a customer’s session, or agencies opening client accounts from one machine. The Akamai HTTP 2 fingerprint decides whether the edge reads the session as an ordinary browser or as something worth a second look.
Libraries are the classic case. Python’s h2, and therefore httpx with HTTP/2 enabled, sends HEADER_TABLE_SIZE 4096, MAX_CONCURRENT_STREAMS 100 and INITIAL_WINDOW_SIZE 65535 — correct, spec-compliant values that no browser sends. Native curl and Go’s net/http negotiate HTTP/2 properly and fingerprint as tooling. Compatibility libraries such as curl_cffi replay a browser’s SETTINGS frame, WINDOW_UPDATE and pseudo-header order alongside its handshake, so their traffic resembles the client they copy rather than a bare library.
tls.peet.ws/api/all in the exact client you are debugging — browser, script or cloud session — and read the akamai_fingerprint field beside the JA3 and JA4 hashes. One request tells you whether the mismatch sits in TLS, in HTTP/2, or in both.
Proxies add a layer people forget. Through a proxy the target server sees the proxy’s TCP stack, not yours. Most proxies run Linux with an initial TTL of 64, so a Windows User-Agent (TTL 128) is inconsistent while a macOS User-Agent (also 64) stays coherent. Three layers now have to agree.
On the defending side, Cloudflare’s bot detection engines combine heuristics, JavaScript detections and Adaptive Intelligence, an ML engine that accounts for most of its detections and returns a 1–99 bot score from request features including headers, session characteristics and browser signals. The __cf_bm cookie smooths that score across requests to cut false positives. The docs, updated in November 2026, note that Adaptive Intelligence retrains more often than the older fixed-version models, so a score can move while your own configuration stays identical.
For site owners the same signal cuts the other way. When a legitimate client — a desktop app with an embedded webview, a corporate proxy that rewrites headers — keeps failing, find the layer that disagrees instead of whitelisting the whole path. Shipping a real rendering engine is usually cheaper than hand-maintaining SETTINGS values that drift with every browser milestone.
One last piece of perspective: this is a consistency check, not a tracker. It is a family signature, not an identifier for a person. Placing it inside what a browser fingerprint is as a whole makes that clearer — the HTTP/2 field is one layer of a stack and only as convincing as the layers around it.
How to Check Your Own HTTP/2 Fingerprint
Reading your own Akamai HTTP 2 fingerprint takes a few minutes and gives you a baseline to compare against after any change to a client, a proxy or a browser build.
- Read the raw string. Open
https://tls.peet.ws/api/allin the client under test. The JSON includesakamai_fingerprintnext to JA3, JA4 and the negotiated protocol. - Record the four fields separately. Write down the SETTINGS pairs, the window increment, the priority count and the pseudo-header letters. Most fixes touch one field at a time.
- Compare against the browser you claim to be. Match the letter order and the window increment first, then the SETTINGS list. Use measured references such as fingerprint-db rather than screenshots.
- Repeat with the proxy on. The HTTP/2 fingerprint should not change; the IP and TCP characteristics will. If the string shifts, your proxy is terminating or re-originating HTTP/2.
- Test from a fresh profile. Cached connections hide the opening frames; a new profile shows the handshake a first-time visitor produces.
- Cross-check the other layers. User-Agent, JA4 prefix, Client Hints and timezone should all name the same platform. Our browser fingerprint test tools comparison lists the echo services worth bookmarking.
One caveat on references: fingerprint-db measures Playwright-bundled Chromium rather than Google Chrome stable, so its “chrome” entries are close to but not identical with a retail install. Measure your own build when the difference matters.
Common Mistakes That Break Consistency
Almost every mismatch traces back to one of these six.
- Setting a User-Agent and stopping there. The header is the cheapest layer to change and the first one a server learns to distrust when the framing disagrees.
- Mixing libraries across layers. A curl_cffi handshake bolted onto a different HTTP/2 stack gives browser-like TLS with library-like SETTINGS — the worst of both.
- Hard-coding old values. The 2017 paper’s examples and the Firefox PRIORITY tuples it lists are historic. Copying them today produces a string that matches nothing currently shipping.
- Assuming the Chrome string is permanent. Chromium 156 measured one set of values in October 2026; the next milestone can change them.
- Ignoring the proxy layer. A Linux proxy in front of a Windows User-Agent leaves a TTL mismatch that no amount of HTTP/2 tuning repairs.
- Reading identical strings as a problem. Two machines on the same Chrome build matching each other is normal. The outlier is a string that matches no shipping build at all.
How Send.win Helps With Akamai Http 2 Fingerprint
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).
One boundary worth stating plainly: making a client stop misrepresenting itself is fine on infrastructure you own or are authorised to use. Using the same tuning to push automated traffic through a platform whose terms forbid it is not — and no fingerprint work fixes a restricted account, which is handled through the platform’s own appeal or verification process.
Where Send.win Fits for Teams Running Many Profiles
Most fingerprint advice assumes one client on one machine. Teams have a different problem: several people opening many client accounts from a handful of laptops, each session needing to look like a normal, internally consistent browser.
Send.win is a browser profile manager built for that shape of work. Each profile carries its own cookies, storage, sessions, fingerprint settings and proxy, with fingerprint protection handled inside the browser engine — the same principle Firefox and Brave apply to canvas, WebGL, audio, fonts and hardware signals, applied per profile instead of once per machine. For HTTP/2 consistency that matters because the process producing the framing is a real Chromium engine in every profile. You are not hand-editing SETTINGS values; you are making sure each identity runs in a browser that sends browser values.
The desktop app, Sendwin Browser, installs locally on Windows 10/11, macOS 12+ and Linux. The cloud browser runs profiles on Send.win’s server in Helsinki, Finland, from any device with nothing to install — handy when a teammate needs to check a client account without touching their own machine. Proxies are configured per profile: residential proxies are included on Pro and Team, bring-your-own HTTP/SOCKS5 is supported, and timezone, locale, WebRTC and geolocation follow the proxy’s exit IP automatically. That last detail removes the most common cross-layer mistake, where a profile’s clock and language disagree with the country its traffic leaves from.
Two honest limits. Everyone works by hand: a person opens the profile and uses it at the keyboard, and there is no way to drive sessions programmatically or leave them running unattended, on any plan. And there is no field where you type arbitrary SETTINGS values; the engine keeps its own values consistent per profile. If you need a fully hand-tuned synthetic client, that is a different tool. If you need many people managing accounts they own or are authorised to manage, with each session coherent from TLS through to timezone, this is the gap it fills. The wider relationship between browser fingerprinting and isolation is the next thing worth reading if you are designing that workflow.
🏆 Send.win Verdict
The HTTP/2 fingerprint is a consistency test, and consistency is exactly what breaks when several people share a handful of browsers. Send.win gives every profile its own cookies, storage and proxy settings inside a real Chromium engine, so the SETTINGS frame, the pseudo-header order and the timezone all come from one coherent identity — and a teammate opening a shared profile lands in a session that is already signed in, without a password changing hands.
See Send.win plans — Pro at $19/mo or $83.88/yr with 150 saved profiles, 5 GB of proxy bandwidth and 6 seats; Team at $49/mo or $251.88/yr with 500 profiles, 20 GB and 16 seats. Both carry a 7-day money-back guarantee on your first card purchase, and the free cloud demo is the no-card way to look inside first.
Frequently Asked Questions
What is the Akamai HTTP 2 fingerprint and how is it built?
The Akamai HTTP 2 fingerprint is a four-field string summarising the frames a client sends at the start of an HTTP/2 connection: SETTINGS identifier-value pairs in order, the connection WINDOW_UPDATE increment, the count of PRIORITY frames before the first HEADERS frame, and the pseudo-header order as letters. Akamai published the format in a 2017 Black Hat Europe paper, and it still reads on any HTTP/2 connection because the protocol’s opening sequence is fixed.
How is it different from JA3 and JA4?
JA3 and JA4 describe the TLS ClientHello, which happens before HTTP/2 starts; the Akamai string describes the HTTP/2 framing that follows. Bot management compares both, plus the User-Agent and Client Hints, because a client that matches on TLS but not on HTTP/2 stands out more than one that is slightly unusual on both layers but consistent.
How can I check my own HTTP/2 fingerprint?
Load an echo service such as tls.peet.ws/api/all in the exact client you want to test and read the akamai_fingerprint field beside the JA3 and JA4 hashes. Repeat with your proxy enabled to confirm the string does not change. Use measured references rather than blog screenshots, since values move between browser releases.
Why am I flagged when I set a realistic Chrome User-Agent?
Because the header is only one layer. Python’s h2 sends HEADER_TABLE_SIZE 4096, MAX_CONCURRENT_STREAMS 100 and INITIAL_WINDOW_SIZE 65535 — valid, spec-compliant and visibly not a browser. A server sees that framing in the first milliseconds of the connection, before it reads your headers.
Do Chrome, Firefox and Safari send different HTTP/2 fingerprints?
Yes, consistently. Chrome declares INITIAL_WINDOW_SIZE 6291456 and orders pseudo-headers m,a,s,p; Firefox declares 131072 and m,p,a,s; Safari omits HEADER_TABLE_SIZE and sends extension 0x9 with m,s,p,a. Window increments differ too, roughly 15.6M, 12.5M and 10.4M. Values change between releases, so re-measure rather than hard-code.
Does a proxy change my HTTP/2 or TCP fingerprint?
On a normal forwarding proxy the HTTP/2 fingerprint passes through untouched, because the proxy relays your frames instead of generating its own. The TCP layer does change: the target sees the proxy’s stack, usually Linux with an initial TTL of 64, so a Windows User-Agent at TTL 128 is inconsistent while a macOS one stays coherent. Proxies that terminate and re-originate HTTP/2 can alter the string, so test with the proxy on.
Can I change my HTTP/2 fingerprint in a normal browser?
There is no setting for it, and no extension that safely rewrites the opening frames. The string is produced by the network stack, so it changes when the browser build changes, not when you flip a preference. That is why per-profile isolation around a real engine is steadier than patching frames after the fact.
Does HTTP/3 remove the Akamai HTTP/2 fingerprint?
It moves the problem rather than removing it. Clients that negotiate HTTP/3 over QUIC have a different transport with its own opening characteristics, and servers falling back to HTTP/2 still read the Akamai string. Akamai’s documentation notes that HTTP/2 must stay enabled for HTTP/3 to serve h2 requests, so both layers stay in play.