HomeToolsNetwork & DNS Tools › HTTP Headers Checker

HTTP Headers Checker — Inspect Response Headers Online

Response headers

Inspect the HTTP response headers for any URL — verify HSTS, CSP, cache settings, redirect chains, and CDN fingerprint, without opening devtools.

Method:

Enter a URL, then check its headers.

About HTTP Headers Checker

Every HTTP response from a server carries two parts: the body (the HTML, image, JSON, or file the client requested) and the headers (metadata that tells the client how to handle that body). Headers control caching, content type, security policies, compression, redirects, CORS permissions, and a dozen other behaviors. Developers and ops engineers check them constantly — debugging a CDN cache miss, confirming a security policy is deployed, tracing a redirect chain, verifying that CORS headers allow a cross-origin fetch. The AT USE HTTP Headers Checker fetches the response headers for any public URL and displays them in a structured, readable format. Enter a URL, choose GET or HEAD, and see the complete header set returned by the server within a few seconds.

The GET method requests the full response including the body, but the headers are returned in the same set either way. HEAD requests only the headers — no response body is transferred, which makes it faster and cheaper on bandwidth. HEAD is the right default when you only need headers: checking if a CDN is active, confirming HSTS is set, inspecting Cache-Control directives. Use GET when you need to confirm headers that some servers only include in a response with a body (certain Content-Length configurations, some server-side vary implementations).

The tool follows redirect chains automatically up to five hops (the default browser limit) and shows each hop's status code and headers in sequence. A 301 to 302 to 200 chain displays each intermediate response — useful when diagnosing a long redirect chain accumulated through domain migrations, canonicalization changes, or misconfigured CDN rules. Toggle "Follow Redirects" off to inspect only the first response and stop at the first non-redirect status.

Security header audit

The checker highlights the presence or absence of six headers with direct security implications: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Missing headers appear with a brief explanation of the risk and a recommended value. The audit is a fast first-pass check that surfaces the most commonly missing headers in seconds — not a comprehensive penetration test, but an immediate signal for the most common misconfigurations.

CDN and cache detection

The tool identifies whether the response passed through Cloudflare, Fastly, Akamai, or Amazon CloudFront by fingerprinting characteristic headers: cf-ray for Cloudflare, x-served-by for Fastly, x-cache and via for CloudFront and Akamai. Cache-Control directives are parsed and displayed in plain language: max-age, no-store, no-cache, s-maxage, and stale-while-revalidate values are shown alongside what each directive means for browser and CDN caching behavior. A cache HIT/MISS indicator appears when the response headers include a CDN-specific cache status field.

CORS header inspection

Cross-Origin Resource Sharing headers — Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Allow-Credentials — are shown when present. Developers debugging cross-origin fetch failures in a browser can check whether the API or CDN origin is returning the correct CORS headers without needing to reproduce the exact cross-origin request in DevTools.

Frequently asked questions

What is the difference between HEAD and GET for header checking?

HEAD requests the headers only — the server processes the request but sends no response body. It is faster, uses less bandwidth, and is the standard method for header inspection. GET requests the full response including the body, which takes longer and transfers more data. Some servers return different or additional headers only when a body is included (Content-Length configurations, certain server-side Vary implementations) — in those cases, GET gives the complete picture. For most security and cache header checks, HEAD is sufficient.

How many redirects does the tool follow?

Up to five redirect hops, matching the default browser redirect limit. Each hop appears in the chain panel with its status code and Location header. If a redirect loop is detected (the same URL appears twice in the chain), the tool stops at five hops. Toggle "Follow Redirects" off to inspect only the first response without following any Location headers.

Why does the tool return different headers than my browser DevTools?

Servers can vary responses based on the User-Agent or Accept headers in the request. The HTTP Headers Checker sends requests with an identifiable bot user-agent, so servers that detect the user-agent and modify their response — different Cache-Control values for bots, different CSP for mobile browsers — may return headers that differ from what a real browser receives. For browser-UA-specific header inspection, use your browser's DevTools Network tab.

What security headers should my site have?

At minimum: Strict-Transport-Security with max-age of 31536000 (one year); X-Content-Type-Options: nosniff; X-Frame-Options: SAMEORIGIN or DENY; Referrer-Policy: strict-origin-when-cross-origin. Content-Security-Policy and Permissions-Policy require more configuration but provide meaningful protection against XSS and browser feature abuse. The security audit panel in the checker shows which of these are present and flags the missing ones.

Does the tool store the URLs I check?

No. Each request is made from the server at the moment you click Check Headers. The URL and the headers returned are not logged or stored. The result is returned to your browser session only.

Can I check headers for a URL behind authentication or on a private network?

The checker can only reach URLs that are publicly accessible from the internet — the same constraint as any external monitoring tool. URLs behind a login session, behind VPN, on a private internal network, or on localhost cannot be reached. For those, use curl directly: <code>curl -I https://your-internal-url.example</code> returns the same header information from within the network.