Free HTTP Headers Inspector
See every HTTP request header your browser sent to reach this page, the IP and country the edge network observed, the timezone and screen size your browser silently revealed, and any proxy, corporate web filter, or CDN sitting in the path. Each header is grouped, explained, and exportable as JSON or as a ready-to-run cURL command for replay.
Privacy: the request stays on the same site you are already visiting. Cookie values are redacted in the display by default. Nothing is logged server side beyond standard Vercel access logs.
Click the button to send a request to the analysis endpoint and see exactly which headers your browser, your proxy, and the edge network attached to it.
Try this example
A user reports that a corporate-issued laptop cannot reach a particular API. You suspect a web filter is rewriting the request. You want to confirm which filter is involved and what it is changing.
- 1Have the user visit this page on the affected laptop and click "Check my browser headers".
- 2Look at the "What we detected" panel. If the path goes through Forcepoint, BlueCoat, Zscaler, McAfee, or Squid the tool names the vendor.
- 3Check the X-Forwarded-For chain to count how many hops the request traversed.
- 4Have the user click "Copy cURL" and paste the command into a ticket. Your network team can replay the same request from a different network to confirm the filter is the cause.
What we detected:
WARN Proxy detected: Forcepoint / Websense
A "Via" header is present (1.1 hosted.websense 61c).
Your traffic is being inspected or rewritten by an
intermediate proxy.
INFO Multiple proxy hops
x-forwarded-for has 2 entries.
OK HTTPS confirmed
The edge layer reports x-forwarded-proto: https.
Apparent client IP: 49.37.114.185
Edge geolocation: Mumbai, MH (IN)What an HTTP request header actually is
Every time your browser asks a server for a page, it attaches a small block of metadata called the request headers. These are key-value pairs that describe who is asking, what kind of response is acceptable, what was visited just before, and how the network was traversed. The server uses them to pick the right format, the right language, the right cache entry, and to make trust decisions.
The exact set varies by browser, by network, and by who is in the middle. A direct request from a recent Chrome on a home network might carry 18 headers. The same request through a corporate web filter behind a CDN might carry 30, with the extras added by the proxy and the CDN.
Most users never see them. They sit invisibly in the request and do their job. When something is broken (you see one IP in your account dashboard, the support agent sees another) the headers are usually where the answer is.
The headers that reveal you the most
User-Agent and the Sec-Ch-Ua family advertise your browser brand, version, OS, and device class. Modern Chromium splits these into "low-entropy" hints (always sent) and "high-entropy" hints (sent only when the server requests them). Firefox and Safari still rely on the older User-Agent string.
Accept-Language gives away every language your browser is configured for, in priority order. This is enough to narrow down a region or first language with high accuracy, even when the IP says otherwise.
Referer (yes, misspelled in the original spec, never corrected) tells the destination which page you came from. Modern browsers default to a referrer-policy of "strict-origin-when-cross-origin" which reduces the leak, but the origin is still sent.
Cookies are unique per origin and let any site recognize you across requests. They are also the largest single source of header bloat. A request with 10 third-party cookies can easily push the header block past 4 KB.
What the proxies and CDNs add
X-Forwarded-For is the most common way an intermediary records the chain of IPs a request passed through. Each hop appends its caller. Reading it left to right gives you the original client first and the most recent proxy last. Servers should trust only the entries added by hops they control.
Cf-Connecting-Ip and Cf-Ipcountry are Cloudflare-specific. When a site is fronted by Cloudflare these are the canonical client IP and country. X-Vercel-Ip-Country, X-Vercel-Ip-City, and X-Vercel-Ip-Timezone are the same idea on Vercel. Most modern hosts have their own variant.
Via names the intermediary itself. Corporate web filters use this header to advertise their vendor and version. If a request to your site arrives with "Via: 1.1 hosted.websense 61c", that request just passed through Forcepoint.
Cdn-Loop is a safety mechanism added by CDNs to detect routing loops between providers. It is harmless to see but informative.
Practical things you can use this tool for
Diagnose "the server sees a different IP than I expect" issues. The Network identity card and the X-Forwarded-For chain together usually pinpoint the culprit (CDN, corporate proxy, or VPN).
Confirm an outbound connection is using HTTPS at every hop. The X-Forwarded-Proto header reveals whether the original request was http or https.
Identify which corporate filter is rewriting your traffic. The detection panel maps vendor signatures to product names, so you can tell your network team which appliance to check.
Audit how much identifying information the browser exposes. Many users do not realize the Sec-Ch-Ua headers and the navigator-side fingerprint together reveal browser vendor, version, OS, language, screen resolution, and CPU core count without any tracking script being needed.
Reproduce a bug from a terminal. Copy the cURL block and replay the exact same request from a different network or a CI environment to isolate the variable.
A note on accuracy
The IP and geolocation come from the edge node that received your request. Edge geo-IP databases are usually accurate to country and reasonably accurate to city, but they are not authoritative. A datacenter IP, a VPN, or a recently reassigned consumer block can show wrong cities.
Browser timezone and screen size are read directly from the browser via the Intl and screen APIs. They reflect what the operating system reports. Anti-fingerprinting browsers (Brave, Tor) deliberately spoof some of these to reduce uniqueness.
Headers can be lied about. Anything in the request can be set to anything by a sufficiently determined client. The values shown are what the server received, not necessarily what is true. Treat the output as a snapshot of the network reality, not as a verified identity.
For a working playbook on what each common header means in security and operations terms, see our [HTTP request headers explained](/blog/http-request-headers-explained-what-each-one-leaks).
How to Use
- 01Click "Check my browser headers". A request goes from your browser to the analysis endpoint and the server returns the headers exactly as it received them.
- 02Read the "Network identity" card for your apparent client IP and the geolocation the edge layer reports.
- 03Scan the "What we detected" panel: HTTPS confirmation, proxy or corporate filter detection, Cloudflare or Vercel edge involvement, multiple proxy hops, and timezone vs IP-country mismatches.
- 04Browse the request headers grouped by purpose: identification, security, content negotiation, caching, CDN, cookies. Switch to "Flat" view if you prefer a single sorted list.
- 05Review the "Client-side fingerprint" panel for what JavaScript can read about your machine without any header at all (screen size, hardware concurrency, languages, timezone).
- 06Use Export JSON for a structured snapshot, or Copy cURL to replay the same request from a terminal.
FAQ
How does this differ from "View > Developer Tools > Network" in my browser?▼
DevTools shows you the request from the browser side, before it leaves your machine. This tool shows the request as it actually arrived at the server, after CDNs, proxies, and corporate filters had a chance to add their own headers (Cf-Connecting-Ip, Via, X-Forwarded-For, X-Vercel-Id, and so on). For diagnosing "why does the server see a different IP than I expect", the server-side view is the one that matters.
Is anything stored or logged?▼
The endpoint runs on Vercel's edge and returns the headers in the response without writing them to a database. The only logs are Vercel's standard access logs which you would generate by visiting any page on this site. Cookie values are redacted in the displayed output by default so you do not paste session tokens into screenshots.
Why is my IP shown as something different from "what is my IP" services?▼
Your apparent IP depends on every hop between you and the server. If you are behind a corporate proxy (Forcepoint, Zscaler, BlueCoat) the IP shown will often be the proxy's egress address. If you are behind a CDN (Cloudflare in front of a site, for example), some headers carry the original client IP and others carry the CDN edge IP. The tool surfaces both so you can see exactly where your traffic appears to come from.
How does it detect a corporate proxy?▼
Proxies typically add a "Via" header naming themselves. Common signatures: "websense" or "forcepoint" indicate Forcepoint Web Security, "bluecoat" or "proxysg" indicate Symantec Blue Coat (now part of Broadcom), "zscaler" indicates Zscaler ZIA, "mcafee" indicates McAfee Web Gateway, "squid" indicates an open-source Squid proxy. The tool maps these signatures to vendor names so you know who is sitting between you and the internet.
What is the timezone vs country mismatch warning?▼
Your IP geolocates to one country (reported by the edge), and your browser separately reports its own timezone (set by the OS). When the two disagree it usually means a VPN, a remote-desktop session into another region, or a manually overridden timezone. Useful when checking whether a session is hitting your service from where the user claims to be.
Why is the cookie value not shown?▼
Cookies often carry session tokens that grant access to your account on this or other sites. Showing the raw value invites accidental leaks (screenshots, copy-paste into chat). The tool reports cookie length so you can still spot oversized cookie headers, which are a common cause of HTTP 431 errors.
What is the cURL export for?▼
It builds a curl command that mirrors the same set of headers your browser sent. Useful for reproducing a bug from the terminal, sharing a repro with a teammate, or testing a backend behind a proxy without launching a browser.
Why does Sec-Ch-Ua not appear in some browsers?▼
The Sec-Ch-Ua family of "client hints" is a Chromium-only standard. Firefox and Safari do not send them, so your output will be shorter on those browsers. The User-Agent header still appears everywhere.
Does this work behind a VPN?▼
Yes. The tool reports whatever the edge layer sees. With a VPN, the IP shown will be the VPN egress IP and the geolocation will reflect that location, not your physical location. The browser timezone often gives away the mismatch.