Free · live registry data · no login

HTTP Headers Viewer

Response headers for any URL.

How it works

See the HTTP response headers for any URL

Enter a URL and our server makes a real request, follows redirects, and returns the status line and every response header from the final hop with a plain-English note for each. Use it to debug caching (Cache-Control, ETag, Age), confirm compression (Content-Encoding), see which CDN sits in front (cf-ray, x-vercel-id, x-amz-cf-id), spot leaked technology details (Server, X-Powered-By) and check that security headers such as HSTS and CSP are present.

Or start from an example

Results appear here after you click Fetch headers.

How this works

  1. 1

    Make a real request

    Our server sends a GET with a browser-like User-Agent and records every response, following redirects to the final URL.

  2. 2

    Capture the headers

    All response headers from the final hop are listed verbatim, lower-cased and sorted, with a copyable raw block.

  3. 3

    Annotate and flag

    Each header gets a plain-English meaning, and we highlight caching, compression, CDN, security and information-leak findings.

Frequently asked questions

How do I check the HTTP headers of a website?
In a browser, open DevTools, go to the Network tab, reload and click the first request to see Response Headers. On the command line use curl -I https://example.com. This tool does the request from our server so you also get the view a crawler or external service sees, without CORS limits.
Which response headers matter most for SEO?
The status code first (200, 301, 404), then X-Robots-Tag (can block indexing), Link rel=canonical when set at header level, Cache-Control and Vary for crawl efficiency, and Content-Type with the right charset. Redirect chains visible in the Location headers also matter.
What does Cache-Control: no-store mean?
Nothing may cache the response, not even the browser. It is right for personalised or sensitive pages and wrong for images, CSS and JavaScript, which should carry a long max-age with immutable so repeat visits are instant.
Should I hide the Server and X-Powered-By headers?
Yes, where possible. They do not help users and they tell attackers your stack and sometimes exact versions. Most servers let you suppress them (server_tokens off in nginx, ServerTokens Prod in Apache, remove X-Powered-By in Express or PHP's expose_php=Off).
Why are headers different from what I see in my browser?
Servers vary responses by User-Agent, cookies, geography and Accept-Encoding, and CDNs add their own headers per edge location. Our request is anonymous and comes from a data centre, so you see the uncached, logged-out, no-cookie version.

Every MailShrine domain includes WHOIS privacy, transfer lock, Anycast DNS with DNSSEC and two business mailboxes.