Browser privacy
HTTP header inspector
See the request headers our server received and compare page navigation, JavaScript requests and browser-readable Client Hints.
Analysing received navigation…
TLS and HTTP
JavaScript Client Hints
- Status
- Reading…
Received headers
| Name | Displayable value | Category | Read |
|---|
Findings and limitations
- Analysing.
A header Via, Forwarded, X-Forwarded-For or a CDN-specific field contains declared information. It can be added, removed or forged; its presence alone does not establish use of an anonymous proxy.
Compare before and after
Run the same test on the same device and save a baseline. Activate your VPN or change one relevant setting, rerun under the same conditions and save the next result.
Save a before result and an after result to compare them.
What this test tells you
Headers describe a request as it reaches the server. They can reveal declared browser information, languages and aspects of the HTTP path. The important nuance is where you observe them: a browser, proxy, content delivery network and our server may expose or modify different fields.
How to run the test
- Open the page in the browser profile you want to inspect and note the connection state.
- Run the request capture; reload if you want to observe additional Client Hints requested by the server.
- Compare navigation and JavaScript request headers, then read JavaScript-accessible hints in their separate section.
How the measurement works
The tool captures headers actually received by our server for the HTML navigation and fetch requests. It also reads Client Hints from JavaScript where the browser permits them.
Sensitive header values are masked before display, and cookie names may remain visible without their values. The module creates no diagnostic log, although hosting infrastructure can independently log requests.
Understanding your results
- Fields match across requests
- Those fields reached our server consistently in these request contexts. This does not mean every website receives the same details.
- Navigation and fetch differ
- Request context, warmed-up Client Hints or intermediary processing can explain different values. Check the field's role rather than assuming manipulation.
- A field is missing or masked
- The browser may withhold it, an intermediary may remove it or the tool may conceal a sensitive value. Missing backend TLS details do not prove the browser used plaintext.
Compare before and after
- Save captures from the same profile, origin and request stage, including whether the page was reloaded.
- Change one browser or connection setting, then repeat the same navigation and fetch sequence.
- Compare matching request contexts. Keep backend protocol and TLS details separate from evidence about the browser-to-edge connection.
Limits of the test
- Forwarded or proxy-like headers alone cannot prove anonymisation or identify a trustworthy intermediary.
- Masking rules cannot recognise every secret placed in an innocently named custom header; review exports before sharing.
What to change, if needed
- Language headers do not reflect your intended preference
- Review browser language order and repeat the same capture after reloading.
- Expected Client Hints are absent
- Check HTTPS, browser support and the reload sequence before treating the absence as a privacy feature.
Frequently asked questions
Are these exactly what my browser sent?
They are what our server received. Intermediaries can add, remove or rewrite fields along the way.
Does a proxy header prove VPN use?
No. It is at most a path clue and can be absent, changed or untrusted.
Sources and technical references
€1 per month 12 months for €10
Subscribe