HTTP Headers Check
Fetch any public URL from our EU servers and inspect the complete HTTP response: status code, every response header, and the full redirect chain.
About HTTP Headers Check
Every time a server answers a web request it returns a set of HTTP response headers alongside the page body. These headers carry the status code, content type, caching directives, security policies, cookies, compression details and the software identifying itself in the Server field. This tool issues a real request to the URL you provide and shows you exactly what came back, so you can read the headers a browser normally hides.
Unlike a quick curl -I, which sends a HEAD request, the check performs a GET and follows redirects one hop at a time, recording each step. That means you see the entire redirect chain, for example an http:// address upgrading to https:// and then to the www or non-www canonical host, along with the status code at every stage. The final response's headers are then listed in full, letting you confirm caching behaviour, content negotiation and which security headers a site actually sets.
Because the request originates from our EU servers rather than your browser, the result is unaffected by your local cache, browser extensions, corporate proxy or cookies. You see the raw server response as an external client sees it. Security-relevant headers are especially useful here: whether Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options and X-Frame-Options are present tells you a lot about how a site is hardened.
The fetch is guarded against server-side request forgery, so it only reaches public internet addresses and refuses private or reserved ranges. Requests time out after a few seconds and follow a limited number of redirects, so a misconfigured redirect loop is reported rather than followed indefinitely.
How to use it
- 1Enter the full URL you want to inspect, including the http:// or https:// scheme.
- 2Run the check to have our EU server issue a GET request and follow any redirects.
- 3Review the redirect chain to see each hop and the status code returned at every step.
- 4Read the final status line (for example 200 OK or 404 Not Found) and scan the full list of response headers.
- 5Look specifically for caching (Cache-Control, ETag), content (Content-Type, Content-Encoding) and security headers (HSTS, CSP, X-Frame-Options) depending on what you are debugging.
Common use cases
- -Debugging redirect chains such as http-to-https or www canonicalisation to catch redirect loops or missing hops.
- -Verifying that caching headers like Cache-Control, ETag and Expires are set the way a CDN or browser needs them.
- -Auditing a site's security headers, confirming whether HSTS, Content-Security-Policy and X-Content-Type-Options are present.
- -Checking the raw response of an API endpoint or asset without browser cache, cookies or extensions interfering.
- -Confirming the exact status code and Content-Type a server returns when a page or resource behaves unexpectedly.
Frequently asked questions
- What are HTTP response headers?
- HTTP response headers are metadata a server sends back with each request, describing the response rather than its content. They include the status code, content type, caching rules, cookies, security policies and the server software, and they control how browsers and caches handle the page.
- How can I check the HTTP headers of a website online?
- Enter the page's full URL into an HTTP headers tool and it fetches the URL server-side and lists the complete response. This one runs the request from EU servers, follows redirects and shows the status code plus every header the site returns.
- How is this different from curl -I?
- curl -I sends a HEAD request and only shows headers for a single response. This tool sends a GET, follows the redirect chain hop by hop and reports each status along the way, which reveals redirects that a single HEAD request would not fully show.
- Which security headers should a website set?
- Common protective headers are Strict-Transport-Security (HSTS) to enforce HTTPS, Content-Security-Policy to limit resource sources, X-Content-Type-Options: nosniff to stop MIME sniffing, and X-Frame-Options or frame-ancestors to prevent clickjacking. This check shows which of them a site actually returns.
- Why does running the check give different headers than my browser?
- The request runs from our EU servers with no cache, cookies, extensions or proxy in the path, so it shows the server's raw response. A browser can add or alter behaviour through caching, service workers and stored cookies, which is why results can differ.
- Does this show request or response headers?
- It shows the response headers the server sends back, along with the status code and redirect chain. These are the headers that describe how the server answered, which is what you inspect when debugging caching, redirects or security configuration.