HTTP Headers Checker
View and analyze HTTP response headers
HTTP Headers Checker tool
HTTP Headers Checker: key facts
- What it does
- View and analyze HTTP response headers
- Category
- Network Tools
- Cost
- Free, with no account, sign-up, or install.
- Your data
- The full URL you enter is sent to allorigins.win, a CORS proxy that fetches the page on your behalf and returns its response headers.
- Last reviewed
- . Report an incorrect result.
Understanding the HTTP Headers Checker
Every web response carries HTTP headers that reveal how a site is configured — its caching rules, security protections, server software, and more. This HTTP Headers Checker fetches a URL's response headers and lays them out, grouped so you can quickly scan the security and caching directives.
Developers debugging cache behavior, SEOs checking for the right directives, and security reviewers auditing protections all use it to see what a server actually sends. It highlights the key security headers, lets you filter to just security or caching headers, and shows the response status.
To bypass the browser's cross-origin restrictions, it fetches the target URL through a public CORS proxy (allorigins.win), which means the URL you check is sent to that third-party service.
Getting a result
- Enter the URL whose headers you want to inspect.
- Click Check Headers.
- Use the All / Security / Caching / Other filters to focus on the headers you care about.
- Read each header's name and value — security headers are highlighted — and copy the set you need.
Fetched through a CORS proxy
Because browsers do not allow a page to read arbitrary cross-origin response headers, this tool routes the request through allorigins.win, a public CORS proxy, which fetches the URL server-side and returns the headers in a form the page can read.
That means the full URL you enter is sent to a third-party service, which then makes the request on your behalf. The target site sees the proxy's address rather than yours. It is worth being deliberate about this: do not check URLs containing tokens, session identifiers, or anything private in the query string.
What comes back is the response header set — content type, caching directives, server identification, security headers, and any custom headers the origin sends.
- Cache-Control and ETag reveal how a response is cached and revalidated.
- Content-Encoding shows whether compression is applied.
- Content-Type carries the charset, whose absence causes encoding bugs.
Reasons to use it here
- It groups headers into security, caching, and other, and highlights the security ones, so an audit takes seconds rather than scrolling raw output.
- Filter tabs let you narrow to exactly the category you are checking.
- It works on any public URL from the browser by routing through a CORS proxy, with no backend of your own required.
- It is transparent that the target URL is sent to the allorigins.win proxy to retrieve the headers, since the browser cannot read them cross-origin directly.
Headers worth checking, and a limitation
A few headers repay attention on any site. Cache-Control determines whether browsers and CDNs can reuse a response, and getting it wrong either wastes bandwidth or serves stale content. Content-Encoding should show compression on text responses, since its absence is one of the easiest performance wins available. Content-Type must be correct and should carry a charset. And the security headers — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options — are worth verifying after every deployment, since a change of proxy or CDN can silently drop them.
Server and X-Powered-By headers disclose software and versions, which is information an attacker can use to target known vulnerabilities. Suppressing them is a small, cheap hardening step.
The main limitation of proxied inspection is that you see the response the proxy received, not the one you would. Anything varying by client — content negotiation, geographic routing, cookie-based personalisation, bot detection — may differ. Your browser's own developer tools show the true headers for your own requests, and a command-line request is better still for scripting across environments.
Frequently Asked Questions
What are HTTP response headers?
They are metadata a server sends with each response, describing things like content type, caching policy, security rules, and the server software. They are not visible on the page itself but govern how browsers and crawlers treat it.
Why does this need a proxy to read headers?
Browser security blocks a page from reading the headers of a response from another origin. To work around that, the tool routes the request through a public CORS proxy, which fetches the URL and returns the headers — so the URL you enter is sent to that proxy service.
Which security headers should a site have?
Common ones include Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, and X-Content-Type-Options. This tool highlights them so you can see at a glance which are present; a dedicated analyzer can grade how complete your coverage is.
