HTTP header checker
Inspect all HTTP response headers returned by any website. View server info, caching, security headers, and more.
Which headers to look at first
Response headers are how a server explains itself: what it returned, how long the answer may be reused, and what the browser should do with it. A handful carry most of the diagnostic value.
- The status code is the first thing to read. 200 is normal, 301 and 302 are redirects, 404 is missing, and 5xx means the server failed. A 200 that returns an error page is a real and surprisingly common bug, because search engines will happily index it.
- Cache-Control decides how long browsers and proxies may reuse the response.
no-storemeans never cache,max-ageis the reuse window in seconds. Static assets serving with a short max age is one of the easiest performance wins there is. - Content-Encoding tells you whether compression is active. Missing entirely on an HTML or CSS response means you are shipping several times more bytes than you need to.
- Location appears on redirects and shows the target. Following the chain here is how you find redirect loops and unnecessary hops.
- Server and X-Powered-By disclose what is running. Neither is needed by any client, and both hand a scanner a version number to look up.
- ETag and Last-Modified let a browser ask whether anything changed and receive a 304 instead of the whole file.
What usually goes wrong
- Redirect chains. HTTP to HTTPS to www to a trailing slash is four round trips before a byte of content. Collapse them into one redirect that lands on the final URL.
- Cache headers on the wrong things. HTML cached for a year means visitors see stale pages. Versioned assets with no caching means every visit re-downloads everything. The two are frequently the wrong way round.
- A cache in front that never gets a hit. If a CDN or proxy is in the path, look for its hit or miss header. A permanent miss usually means the origin is sending headers that forbid caching.
- Cookies set on static files. Cookies on images and scripts defeat most shared caching and add bytes to every request.
- Headers grow until requests fail. Enough cookies and a request exceeds the server's header buffer, producing a 400 or a 431 response that looks like the site is down for one visitor only.
Common questions
What is a good response time here?
Under 200 milliseconds is good, under 500 is acceptable, and over a second means the server is doing work it could avoid or cache. This measures the server response only, not the full page load, so a fast number here with a slow page points at assets and rendering rather than the backend.
Should I remove the Server header?
Removing the version is worth doing, since it is free and stops a scanner matching you to a known vulnerability list. Removing the header entirely is fine too. Treat it as tidying up rather than as security, because it delays an attacker and does not stop one.
Why does my page show 200 when it is clearly an error?
The application caught the error and rendered a friendly page without changing the status code. Search engines then index the error page as valid content. Error pages should return the matching code, 404 for missing and 5xx for failures, and only the body should be friendly.
How do I tell whether my CDN is actually caching?
Look for the provider's cache status header in the response and request the same URL twice. The first may be a miss, the second should be a hit. A permanent miss means something in the origin response, often Cache-Control or a cookie, is telling the CDN not to store it.