Understanding HTTP Headers Checker
Learn how the checker works, how to interpret its output, and how to use the results in development, troubleshooting, and technical SEO workflows.
What HTTP response headers are
HTTP response headers are name-value fields sent before a response body. They describe the status and representation, tell browsers and intermediaries how to cache content, establish security policies, enable or restrict cross-origin access, and expose operational metadata. A header checker makes this otherwise invisible layer readable without requiring command-line tools or browser developer panels. It reports the final public response after safe redirects and groups common fields by purpose.
Headers are instructions and metadata, not the page content itself. Content-Type identifies the media format, Cache-Control influences reuse, Content-Encoding indicates compression, and Location points to a redirect destination. Security fields such as Content-Security-Policy and Strict-Transport-Security affect browser behavior. Server and X-Powered-By may hint at infrastructure, although proxies can remove, replace, or intentionally generalize them.
How to use the headers checker
Enter the exact public URL you want to test, including its path when page behavior matters. The server validates the destination, follows a limited redirect chain, and returns the headers on the final response. Start with HTTP status, final URL, redirect count, and response time. Then examine the grouped content, caching, security, server, and access-control fields before reviewing the complete table for application-specific values.
Test more than the homepage. HTML documents, images, JavaScript bundles, API responses, downloads, and error pages often use different cache and security policies. A CDN can also add or overwrite headers at the edge. Compare an origin response only when you are authorized and know how to reach it safely; ordinary visitors receive the public edge response, so that is usually the most relevant result for debugging production behavior.
Content and caching headers
Content-Type should match the delivered representation and include an appropriate charset for text. Content-Length may be absent with streaming or transfer encoding. Content-Encoding commonly reports gzip or br compression. ETag and Last-Modified are validators that allow conditional requests, while Cache-Control defines freshness, storage permissions, and revalidation requirements. Expires is an older date-based freshness mechanism; Age indicates how long a shared cache has stored a response.
Caching requires context. public permits shared caching, private restricts storage to a user-specific cache, no-store asks caches not to retain the response, and no-cache allows storage but requires validation before reuse. s-maxage targets shared caches, while stale-while-revalidate can serve an older response during background refresh. A long max-age is excellent for fingerprinted static assets but dangerous for mutable HTML unless purge and versioning strategies are deliberate.
Important browser security headers
Content-Security-Policy restricts the sources from which scripts, styles, frames, images, and other resources may load. Strict-Transport-Security tells supporting browsers to use HTTPS for future connections. X-Content-Type-Options: nosniff reduces MIME confusion, while frame-ancestors in CSP or the older X-Frame-Options controls embedding. Referrer-Policy limits referrer information, and Permissions-Policy governs access to selected browser capabilities.
A missing header is not automatic proof of a vulnerability, and a present header can still be ineffective if its value is overly broad or malformed. Security depends on application behavior, cookies, authentication, TLS, dependency integrity, and server configuration as well as headers. This checker reports presence and values; it is not a penetration test, CSP evaluator, TLS scanner, or guarantee that an implementation is secure.
CORS and access-control fields
Cross-Origin Resource Sharing headers tell browsers whether JavaScript from another origin may read a response. Access-Control-Allow-Origin identifies permitted origins, Allow-Methods and Allow-Headers control preflight requests, and Allow-Credentials determines whether credentials may be included. These rules are enforced by browsers; they do not prevent a server, command-line client, or other non-browser system from requesting a public URL.
Avoid treating a permissive wildcard as universally wrong. Public fonts, read-only assets, and open APIs can intentionally allow any origin. Conversely, reflecting arbitrary Origin values while allowing credentials is risky. CORS behavior may depend on the request's Origin header and method, so a simple GET without a custom Origin cannot reproduce every preflight scenario. Inspect application configuration and test authorized use cases directly.
Technical SEO and performance considerations
Search crawlers need a successful response and a supported content type before they can process page markup. Incorrect redirects, 4xx errors, 5xx outages, or an HTML page served as a download can disrupt crawling. X-Robots-Tag can control indexing for HTML and non-HTML resources, although absence does not override a meta robots tag in the document. Review both headers and the Open Graph & Meta Tag Checker when diagnosing indexation or canonicalization.
Headers also influence Core Web Vitals indirectly. Efficient compression and cache policies reduce transfer cost and repeat-load latency. Preload Link headers can prioritize critical resources but waste bandwidth when overused. CDN cache indicators help confirm whether content is reaching the edge. Response time in this report is a single server-to-server observation, not a user-centric performance metric; field data and browser profiling remain necessary for LCP, INP, CLS, and TTFB analysis.
Troubleshooting missing or unexpected headers
A framework may set a header correctly at the application layer only for a reverse proxy, platform configuration, or CDN rule to replace it. Duplicate policies can be combined in ways that change their meaning. Cached responses may preserve an older configuration. Start at the public response, identify each delivery layer, clear or purge caches, and compare a known static asset with a dynamic route. Check redirects separately because the 3xx response can have different headers from its destination.
Header names are case-insensitive, and this report normalizes them for comparison. Some values are intentionally omitted by browsers or intermediaries, while Set-Cookie may be treated specially by server runtimes. Authentication, geography, request method, accepted encoding, and user-agent can all affect the response. Use this checker as a fast baseline, then reproduce a specific issue with browser network tools or an authorized command-line request containing the relevant request headers.
Related website tools
Continue the investigation with these closely related checks.
Redirect & HTTP Status Checker
Trace redirect chains, status codes, final destinations, and response timing.
Open toolRobots.txt Checker
Fetch, parse, and test public robots.txt directives and sitemap declarations.
Open toolOpen Graph & Meta Tag Checker
Audit SEO metadata, canonical tags, Open Graph fields, and Twitter cards.
Open toolYou can also return to the Website CMS Detector to identify a site's content management system, framework, WordPress theme, and visible plugins.
Frequently asked questions
Header field names are case-insensitive. Values can have their own syntax and case rules, so they should be interpreted according to the relevant specification.