How to Check HTTP Headers

Quick answer: open browser Developer Tools, select Network, reload the page, click the document request, and inspect Headers. From a terminal, run curl -I https://example.com for one response or curl -IL https://example.com to follow the redirect chain.

Headers explain what happened before the browser rendered the page: status, redirects, content type, caching rules, compression hints and security policy.

Check headers in Chrome, Edge or Firefox

1. Open the page.
2. Open Developer Tools.
3. Select the Network panel.
4. Reload the page so requests are captured.
5. Click the first request with type document.
6. Open its Headers section.

You will see request headers sent by the browser and response headers returned by the server. Enable Preserve log before navigation when diagnosing a redirect, otherwise the earlier response may disappear.

The Network panel is also the right place to inspect a specific CSS, JavaScript, image or API request; each resource can have different caching and content-type headers.

Check headers with curl

Print headers for the first response:

curl -I https://example.com

Follow redirects and print every hop:

curl -IL https://example.com

Request a compressed response and show verbose connection details:

curl --compressed -I -v https://example.com

Use -X GET carefully: curl -I sends a HEAD request, and a poorly configured server can answer HEAD differently from GET. To discard a real GET body while keeping headers:

curl -sS -D - -o /dev/null https://example.com

Headers to inspect first

Status

The first line contains the protocol and status, such as 200, 301, 404 or 500. A successful final page can still hide unnecessary redirect hops, so inspect the entire chain.

Location

A 3xx response uses Location for the next URL. Check for HTTP-to-HTTPS, www-to-non-www and trailing-slash rules. Multiple canonicalization hops waste time and complicate debugging.

Content-Type

This identifies the media type, such as text/html; charset=UTF-8 or application/json. Incorrect types can make browsers refuse scripts, download a page, or decode text incorrectly.

Cache-Control and Expires

Cache-Control describes browser and shared-cache behavior. Common directives include max-age, public, private, no-cache and no-store. no-cache means revalidation is required; it does not literally mean “never store.”

Compare the HTML document with static assets. Long-lived fingerprinted CSS and JavaScript can be cached aggressively, while personalized HTML should not be publicly cached.

ETag and Last-Modified

These validators let a client ask whether stored content is still current. A server may legitimately use one, both or neither depending on its caching design.

Content-Encoding

Values such as br or gzip show the representation was compressed for transfer. Test with a client that advertises supported encodings; curl --compressed does this.

Security headers

Useful policies include:

• Strict-Transport-Security for future HTTPS enforcement;
• Content-Security-Policy for controlling resource origins;
• X-Content-Type-Options: nosniff;
• Referrer-Policy;
• Permissions-Policy;
• frame restrictions through CSP frame-ancestors or the older X-Frame-Options.

Do not paste a generic Content Security Policy into production. Build and test it against the resources the site actually needs.

Diagnose caching with headers

CDNs and managed hosts often add headers such as Age, Via, X-Cache or vendor-specific cache status. Their exact meanings vary by provider.

Compare two logged-out requests. Look for a changing Age, cache hit/miss indicators and Vary. If authenticated or personalized pages are cached publicly, treat it as a correctness and security issue.

When WordPress edits do not appear, headers help locate the stale layer. Combine them with the steps in WordPress Changes Not Showing.

Avoid common interpretation mistakes

• A Server header is not reliable proof of the origin stack; a proxy may generate it.
• Missing browser-visible headers may be restricted from JavaScript by CORS, even though the Network panel shows them.
• A HEAD response can differ from GET.
• One URL does not represent the whole site.
• More security headers are not automatically better if their values are broken or ineffective.

Check the exact canonical URL, at least one static asset, an error page and any API endpoint involved in the problem. Save the raw output when comparing changes so the diagnosis is based on evidence.