HTTP Header Checker
Enter a URL to inspect every HTTP response header it returns, plus a security-header analysis. The request is made server-side, so it works on any public site.
What is an HTTP header checker?
HTTP response headers are key-value pairs sent by a web server alongside every response, carrying metadata about content type, caching policy, security constraints, and more — they are invisible to end users but critical for how browsers, CDNs, and API clients behave. A browser-based tool cannot read headers from arbitrary URLs because the Same-Origin Policy and CORS restrictions prevent JavaScript on one origin from inspecting responses from another origin; the browser either blocks the request or strips the headers entirely. A server-side checker proxies the request from a neutral origin, receives the full unfiltered response headers, and returns them to you — giving an accurate picture of what the server actually sends.
Security headers explained
Strict-Transport-Security
Tells browsers to connect exclusively over HTTPS for a specified duration, preventing SSL-stripping attacks where a man-in-the-middle downgrades the connection to plaintext HTTP before it reaches your server.
Recommended: max-age=31536000; includeSubDomains; preload
Content-Security-Policy
Defines which sources of scripts, styles, images, fonts, frames, and other resources the browser is permitted to load, dramatically reducing the attack surface for Cross-Site Scripting (XSS) and data-injection attacks.
Recommended: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none' (tighten per application)
X-Frame-Options
Controls whether the page may be embedded in an iframe, object, or embed element on another origin, preventing clickjacking attacks where an attacker overlays your page inside a transparent frame to steal clicks.
Recommended: DENY (or SAMEORIGIN if you embed the page on your own domain)
X-Content-Type-Options
Instructs the browser not to sniff the content type of a response and to trust only the declared Content-Type header, blocking MIME-confusion attacks where a browser misinterprets an uploaded file as executable script.
Recommended: nosniff
Referrer-Policy
Governs how much of the current URL is included in the Referer header when navigating to another page or making a sub-resource request, limiting accidental leakage of sensitive URL parameters or internal paths to third parties.
Recommended: strict-origin-when-cross-origin
Permissions-Policy
Allows a server to selectively enable or disable browser features and APIs — camera, microphone, geolocation, payment, and others — for the page and any embedded iframes, reducing the damage radius if third-party scripts are compromised.
Recommended: camera=(), microphone=(), geolocation=(), payment=() (allow only what your application explicitly requires)
Caching headers
Cache-Control is the primary directive for controlling how and how long a response may be stored by browsers, reverse proxies, and CDNs; common values include no-store (never cache), no-cache (cache but always revalidate), private (browser only, not shared caches), and max-age=N (cache for N seconds). ETag is a fingerprint the server assigns to a specific version of a resource; on subsequent requests the browser sends the fingerprint in If-None-Match and the server responds with 304 Not Modified if nothing has changed, saving bandwidth without re-downloading unchanged content. Last-Modified serves the same revalidation purpose using a timestamp instead of a fingerprint, paired with If-Modified-Since on conditional requests; it is less precise than ETag because filesystem timestamps can be unreliable across deploys. Expires is an older HTTP/1.0 header that sets an absolute expiry date-time for cached content; it is superseded by Cache-Control max-age in modern stacks but may still appear on legacy servers and CDN edge responses. Vary tells caches which request headers were used to select the response, so a cache serving both gzip and brotli responses uses Vary: Accept-Encoding to store them separately and serve the right variant to each client.
CORS headers
Cross-Origin Resource Sharing headers let a server explicitly opt resources into cross-origin access that the browser's Same-Origin Policy would otherwise block. Access-Control-Allow-Origin specifies which requesting origins may read the response — a value of * allows any origin but prevents the browser from sending credentials, while an explicit origin like https://app.example.com is required when cookies or Authorization headers are involved. Access-Control-Allow-Methods lists the HTTP verbs permitted in cross-origin requests beyond the safe defaults (GET, HEAD, POST with simple content types), and Access-Control-Allow-Headers lists the non-simple request headers the client is allowed to send; both matter for preflight OPTIONS requests that browsers issue before any non-trivial cross-origin call. Misconfigured CORS — particularly reflecting the Origin header unconditionally or using Access-Control-Allow-Origin: * alongside Access-Control-Allow-Credentials: true — is a common vulnerability that can expose authenticated data to attacker-controlled pages.
Frequently asked questions
Why can't I just check headers in the browser DevTools Network tab?
The browser Network tab shows headers for requests your own page makes, but you cannot use JavaScript to programmatically fetch an arbitrary third-party URL and read its response headers. The browser enforces the Same-Origin Policy: if the target server does not include permissive CORS headers, the browser blocks the response or omits it from scripts entirely. A server-side tool makes the request from its own origin, receives the complete headers, and forwards them to you without any browser restriction in the way.
What is a security header?
A security header is an HTTP response header whose purpose is to instruct the browser to apply a specific protective behavior — for example, refusing to render the page inside an iframe, blocking mixed HTTP content on an HTTPS page, or restricting which scripts are allowed to run. They are set by the web server or application, require no client-side code, and are one of the lowest-effort layers of defence against a range of common web attacks.
How do I add security headers to my site?
The method depends on your stack. On nginx, add headers with the add_header directive in the server or location block. On Apache, use the Header directive inside .htaccess or a VirtualHost config, with mod_headers enabled. On Caddy, use the header directive in your Caddyfile. Application frameworks (Express, Django, Laravel, Next.js) can set headers programmatically in middleware, and CDNs like Cloudflare allow header rules at the edge without touching your origin server. After adding headers, re-run the checker to confirm they appear in the response.
What is HSTS and why does it need a high max-age?
HTTP Strict Transport Security (HSTS) tells the browser to remember that your site must only be accessed over HTTPS for the duration specified in max-age (in seconds). A low value like 60 seconds provides almost no protection because an attacker only needs to intercept a single visit outside that window. A value of at least 31536000 (one year) ensures the browser enforces HTTPS even if a user types your URL without a scheme. The preload flag is an additional step to submit your domain to browser preload lists, so the HTTPS enforcement is baked in before the first visit — but preloading is irreversible until max-age expires, so include it only when you are certain the entire domain (including all subdomains if you set includeSubDomains) will support HTTPS permanently.
What does the tool do with the URL I enter?
The tool makes a server-side HTTP GET request to the URL you provide, records the response status code and response headers, and displays them. It does not store your URL beyond the duration of the request, does not follow more than a small number of redirects, and does not execute any JavaScript on the target page. It is functionally equivalent to running curl -I against a URL from a neutral server — useful for seeing exactly what headers a real HTTP client receives.
Is the HTTP Header Checker free to use?
Yes, the tool is free with no account required. It is provided as a diagnostic utility for developers debugging their own servers, cron job endpoints, and API integrations. Rate limits apply to prevent abuse.
If a cron job makes an HTTP request to an external API or webhook endpoint and starts returning unexpected status codes or behaving differently, the HTTP Header Checker lets you inspect that endpoint's response headers directly — surfacing mismatches like a Content-Type that changed from application/json to text/html, a missing CORS header that broke a fetch from your worker, or a Retry-After header your job handler is ignoring. Because CronJobPro already monitors whether your jobs complete on schedule and alerts on failures, pairing it with the header checker gives you a fast path from "my job failed" to "the endpoint it calls is returning a 301 redirect with no Location header" without needing to set up a local proxy or curl from a remote machine.