Web status · Web status & headers
HTTP response headers: what your server is actually sending
When a server returns a page, it sends headers before the body. These headers tell the browser how to handle the response: cache it or not, compress it or not, embed it in an iframe or not, send a CORS request from another origin or not. Most are invisible to users. A few, like Content-Type and Set-Cookie, are visible indirectly. The bad ones, like missing security headers, are invisible until something breaks.
TL;DR
Every HTTP response carries 10-20 headers. Most are invisible to users, but they control caching, security, content negotiation, and tracking. Here is what each major one does.
The headers every response should have
Content-Type tells the browser what the body is (text/html vs application/json vs image/png). Cache-Control tells it how long to cache. Content-Encoding tells it the body is compressed (gzip, br). Server and Date tell you who served it and when. Strict-Transport-Security tells the browser to use HTTPS for the next 6–12 months. X-Content-Type-Options: nosniff tells the browser to not guess the content type.
Security headers worth checking
Content-Security-Policy restricts what scripts and styles the page can load. X-Frame-Options prevents the page from being embedded in an iframe (clickjacking). Referrer-Policy controls how much referrer information the browser sends. Permissions-Policy disables features like camera, microphone, geolocation by default. A-F grade on /headers-checker/ measures these.
Caching headers
Cache-Control: max-age=3600 means "cache this for 1 hour". ETag is a fingerprint of the content — the browser sends If-None-Match back and the server returns 304 if the content is unchanged. Last-Modified is the older equivalent. Cloudflare and other CDNs add Age and CF-Cache-Status headers you can use to debug caching.
When headers cause problems
A missing Content-Type header makes the browser guess, which can cause XSS vulnerabilities. A wrong Cache-Control header makes your pages cache-stale (visitors see old content). A CORS header that is too permissive lets other sites read your responses (security issue). A CORS header that is too restrictive breaks legitimate cross-origin requests. The right balance depends on what your site does.
Try it →
Run the HTTP headers tool on sitetrace.it.com — paste a value and get an instant answer.
Open HTTP headers