---
title: "HTTP\/2 fingerprint"
url: https://proxy.wiki/glossary/http2-fingerprint/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-09-06
updated: 2026-09-06
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# HTTP/2 fingerprint

> An HTTP/2 fingerprint identifies a client from how it opens and drives the connection, rather than from the content of its headers.

**An HTTP/2 fingerprint identifies a client from how it opens and drives the connection, rather than from the content of its headers.** It is derived from frames, so it survives any amount of header editing and applies to every request on the connection.

## Where the signal lives

The first thing each endpoint sends after the connection preface is a SETTINGS frame. Which parameters a client chooses to send, what values it gives them and in what order are all implementation choices, and they are consistent for a given build.

| Signal | Why it varies between clients |
| --- | --- |
| SETTINGS parameters sent | A client may omit any parameter and inherit the protocol default |
| Values chosen | Flow-control and frame-size preferences differ by implementation |
| Initial WINDOW_UPDATE | Some clients immediately enlarge the connection window; others do not |
| Pseudo-header order | :method, :authority, :scheme and :path are emitted in a fixed per-client order |
| Priority information | Sent by some clients, absent in others |

## The defaults are the reference point

RFC 9113 gives initial values for the settings an endpoint does not send: the initial stream flow-control window is 65,535 octets and the maximum frame payload is 16,384 octets. A client that never mentions either inherits both, so the set of parameters it does send is itself distinguishing. The registry of parameter identifiers is maintained by IANA.

## What this means for scraping

Matching a browser’s [TLS handshake](/glossary/ja3-fingerprint/) and then driving the connection with a general-purpose HTTP library produces a contradiction: a browser handshake followed by a library’s frame pattern. The mismatch is a stronger signal than either half on its own, in the same way a browser [user agent](/glossary/user-agent/) on a scripting client’s handshake is.

Consistency across layers is the requirement. Either the whole stack imitates the browser, or you use the browser.

## Commonly confused with

[TLS fingerprinting](/glossary/tls-fingerprinting/) happens before any HTTP frame exists. HTTP/2 fingerprinting happens after the handshake succeeds, so a target can accept your connection and still classify you on the frames that follow.

## Frequently asked questions

### Can I change my HTTP/2 fingerprint by editing headers?

No. The fingerprint is taken from SETTINGS values, window updates, pseudo-header ordering and priority information, none of which are header content. Editing headers leaves every one of those untouched. Changing the fingerprint means changing the HTTP/2 implementation or using a browser engine.

### Does forcing HTTP/1.1 avoid the problem?

It removes this particular signal and adds another, because a client negotiating away from HTTP/2 against a site where browsers use it is itself unusual. It also changes connection behaviour and concurrency. Consider it a different trade rather than an escape.

### Which HTTP/2 details are actually distinguishing?

The parameters a client sends rather than inherits, the values it picks, whether it immediately enlarges the connection window, and the order of the pseudo-headers. RFC 9113 supplies defaults for anything omitted, so omission carries information as reliably as the values themselves.

## Sources

1. [RFC 9113: HTTP/2, the SETTINGS frame and its initial values](https://www.rfc-editor.org/rfc/rfc9113.html)
2. [IANA: HTTP/2 settings and frame type registries](https://www.iana.org/assignments/http2-parameters/http2-parameters.xhtml)