Short answer: An HTTP header check requests a minimal public response and returns selected headers with bounded values. It helps spot transport, cache, content and policy signals, but it does not authenticate, execute JavaScript or prove overall security. This page gives a bounded public observation for HTTP Header Checker, not a universal promise about every user, provider or future request.
What it measures
The tool sends an unauthenticated request and selects defined fields, capped at 300 characters. It observes one URL and method and does not merge redirect or browser headers. Read the form status and result together. A missing or unavailable upstream response is different from a clean result, and the submitted input must remain attached to the evidence.
Protocol and standards
RFC 9110 defines HTTP field semantics. Strict-Transport-Security and Content-Security-Policy have additional standards, while Cache-Control describes caching directives. Meaning depends on route, status and client support. The linked primary references explain the terminology and normative boundaries. Implementations, caches, trust stores, resolver behavior and operator policy can still affect a live observation, so standards should guide interpretation rather than replace it.
Inputs and validation
Enter an absolute public http or https URL. Private targets and credentials are rejected. Homepage, API and asset routes may intentionally use different policies. Use only the public value requested by the form. Remove credentials, fragments, private addresses and unrelated paths. Validation protects the upstream request and prevents private material from entering a diagnostic workflow.
Outputs and evidence
The result lists selected fields, status and bounded values. A missing field may be intentional; duplicate fields can be interpreted differently. Record URL and status with every value. Preserve the input, status and check time when sharing the result. Empty, unavailable and positive responses have different meanings. Do not combine rows from separate checks without keeping their names, protocols and timestamps visible.
Worked example
A long cache directive may suit a fingerprinted asset but be unsafe for personalized HTML. A CSP may allow more sources than intended, so review directives rather than presence alone. This is an explanatory example, not a claim that the same value exists for another domain or endpoint. Re-run after a controlled change with equivalent inputs so the difference can be attributed safely.
How to interpret the result safely
Read headers with status and content. HSTS, cache and CSP have different scopes. Never infer CORS, authentication or privacy from one unrelated header; compare origin and CDN where possible. First ask whether the tool measured the question you actually have. Then compare an important conclusion with an independent source such as provider configuration, a real message, an authoritative registry, a browser observation or an operator log.
Limitations and upstream behavior
Headers vary by path, method, edge, compression, cookies and deployment. No browser enforcement, all-field inspection or authenticated flow is included. Public and logged-in responses may differ. Network location, cache state, rotation, rate limits and policy can change public results. Use the upstream operator documentation for remediation or account action. This tool reports uncertainty instead of inventing a value.
Troubleshooting checklist
- Remove credentials and use a public URL.
- Compare exact route and status with origin and CDN.
- Inspect redirects, request headers and browser support when behavior differs.
Key takeaways
- The tool sends an unauthenticated request and selects defined fields, capped at 300 characters. It observes one URL and method and does not merge redirect or browser headers.
- Read headers with status and content. HSTS, cache and CSP have different scopes. Never infer CORS, authentication or privacy from one unrelated header; compare origin and CDN where possible.
- Headers vary by path, method, edge, compression, cookies and deployment. No browser enforcement, all-field inspection or authenticated flow is included. Public and logged-in responses may differ.
FAQ
Does it send authorization headers?
No. The request is unauthenticated and minimal.
Does CSP guarantee no XSS?
No. Escaping, dependency control and testing remain necessary.
Why do headers differ between pages?
Routes, methods, status, CDN rules and content types require different policies.
Can cache headers prove freshness?
No. Age, validators, revalidation and intermediaries also matter.
Sources
Primary references used for this guide: