# Browser fingerprinting

Browser fingerprinting identifies a client from the combination of attributes it exposes: user agent, screen size, fonts, canvas and WebGL rendering, time zone, language, installed features, and at the transport level the exact way its TLS and HTTP/2 stacks negotiate. The combination is often unique, so a website can recognise the same automation across many IP addresses. Proxies change the IP; they do not change the fingerprint.


## Two families

- **Browser-side**: what JavaScript can read. Headless browsers and automation frameworks leak characteristic values unless configured otherwise.
- **Network-side**: the TLS ClientHello (cipher order, extensions) and HTTP/2 settings identify the client library. A Python script does not look like Chrome, whatever user agent it sends.


## Consistency with the exit

Detection systems cross-check fingerprint and IP: a Berlin residential exit with an American time zone and English locale contradicts itself. Align language, time zone and, for browsers, the profile with the country you target.


## One fingerprint, one session

The same fingerprint from a hundred rotating IPs within a minute is a stronger bot signal than one IP would be. Pair rotation with fingerprint variety, or pin a sticky session to one profile.


## How it works at ProxShift

ProxShift is deliberately neutral here: the gateway relays your TLS and HTTP exactly as sent and never terminates TLS, so what the target sees is your client's own fingerprint behind a residential, ISP, datacenter or mobile address.

Source: https://proxshift.com/glossary/browser-fingerprinting