HTTP Headers
Inspect response headers and redirect hops without downloading the response body.
Response headers describe how an endpoint behaves
HTTP response headers can expose cache directives, content metadata, redirect targets, authentication challenges, cookies, transport-security policies and other server behavior. A header must always be interpreted in the context of the application and response status.
This tool uses HEAD instead of downloading the page body
The checker requests response metadata with HTTP HEAD. Most compliant servers return the same relevant response headers as GET without sending the representation body. Some applications handle HEAD differently or do not support it, so results can differ from a browser GET request.
Redirects are inspected one hop at a time
Automatic redirect following is disabled. If a public response points to another location, the destination is parsed, resolved and checked again before a new connection is allowed. This prevents a validated public URL from silently redirecting the server toward a private or reserved address.
Cache-Control
Cache-Control contains directives that influence caching in browsers and shared caches such as proxies and CDNs. Directives such as no-store, no-cache, max-age, public and private have different meanings and should not be interpreted as simple on/off switches.
Security headers are signals, not a complete security score
Headers such as Strict-Transport-Security, Content-Security-Policy and X-Content-Type-Options can be important defensive controls, but their presence alone does not prove that an application is secure. Correct values, scope, browser behavior and the rest of the application architecture still matter.