What this tool does
Every time your browser, app, or script makes an HTTP request, it sends a block of request headers — small key/value pairs that travel ahead of the body and tell the server who is asking, what they can accept, and how they arrived. This page simply echoes back the headers you just sent on this exact request, in the order our server received them. Nothing is fetched from a third party; you are looking at your own connection. That makes it the fastest way to answer questions like “is my proxy rewriting anything?”, “what does a VPN actually expose?”, or “why does this site think I'm on mobile?”
The headers worth knowing
- User-Agent — your client's self-identification. Don't trust it for security decisions; it's trivial to spoof. We decode it into browser, OS, and device on the user-agent tool.
- Accept / Accept-Language / Accept-Encoding — content-negotiation preferences: which MIME types you want back, which human languages you prefer, and which compression algorithms (
gzip,br,zstd) your client can decode. Servers use these to pick the best representation of a resource. - X-Forwarded-For / X-Real-IP — added by our reverse proxy (Caddy) so the application can see the original client IP from behind the proxy. The full forward chain is also shown on the home page.
- X-Forwarded-Proto — records the original request scheme (http or https) before TLS was terminated upstream. We use it to confirm encryption is on.
- Sec-CH-* (Client Hints) — Chromium's structured replacement for the ever-growing User-Agent string. The browser advertises pieces like platform and mobile flag, and servers can request more detail on demand. Privacy-focused browsers often suppress these.
- Sec-Fetch-* — Fetch Metadata headers that describe the context of the request: whether it's a top-level navigation or a sub-resource, and which site it originated from. They're a useful signal for blocking cross-site request forgery.
How headers reach us through proxies
Almost no production request travels straight from your machine to the origin server. Between you and the application sit CDNs, load balancers, and reverse proxies, and each one can add, rewrite, or strip headers. The clearest example is X-Forwarded-For: every hop appends the address it saw, so the header grows into a left-to-right chain that reads original client first, nearest proxy last. The rule that trips people up is trust direction. Only the entry your own trusted proxy added is reliable; everything to its left was supplied by an untrusted client and can be forged. That is why frameworks make you configure exactly how many proxy hops to trust before they'll believe a forwarded IP — and why this page exists, so you can see the raw chain rather than a value some library already “cleaned up” for you.
What is redacted, and why
Three headers are deliberately hidden. Cookie, Authorization, and Proxy-Authorization are replaced with [redacted] server-side before anything renders, because they routinely carry session tokens, API keys, or login credentials. A debug page that printed those would happily leak a live secret into a screenshot, a shared URL, or a server log. The redaction happens on both this page and the JSON endpoint, so the data is safe to copy and paste into a bug report. If you genuinely need to inspect a cookie or bearer token, your browser's devtools network panel shows it to you privately.
Frequently asked questions
Why are my Cookie and Authorization headers hidden?
They contain secrets. We strip the values of Cookie, Authorization, and Proxy-Authorization server-side so a session token or API key can never end up in a screenshot or log. Read them in your browser devtools instead, where they stay private to you.
Why does X-Forwarded-For show more than one IP?
Each proxy the request passes through appends the address it saw, so a site behind a CDN and its own reverse proxy produces several entries. Trust only the value your own proxy added; everything to its left is client-supplied and spoofable.
Can I trust the User-Agent to identify a visitor?
No. It's a free-text string the client chooses and can change at will. It's fine for rough analytics and content negotiation, but never for a security decision — the same caveat applies to the newer Sec-CH-* Client Hints.
JSON API
Need the machine-readable version? GET /api/headers returns the same data as JSON, with Authorization, Cookie, and Proxy-Authorization redacted exactly as they are here. It's handy for shell scripts that need to confirm what a client is sending through a tunnel or proxy.
Related tools
Decode the raw User-Agent on the user-agent parser, see your public address and the full forward chain on what is my IP, inspect a site's security and certificate headers with the TLS checker, and read what websites can see about you for the bigger picture.