Hypertext Transfer Protocol (HTTP) Header Checker

Pass {{ statusCounts.pass }} Warn {{ statusCounts.warn }} Fail {{ statusCounts.fail }} Info {{ statusCounts.info }} Hops {{ chain.length }} Cache {{ cacheClassification }}

{{ profileLabel }} profile {{ method }} request {{ summaryTargetLabel }} Manual run

Ignored {{ extraLinesIgnored }} extra line(s). This checker evaluates only the first non-empty URL.

Inspecting headers…

URL target:

Format: https://example.com or https://example.com/path.

Analysis profile:

Accepted: Balanced, Strict, or API profile.

Live request method:

Accepted: HEAD or GET; cURL preview follows the same method.

User-Agent profile:

Choose Default, Desktop, Mobile, Crawler, or Custom.

Custom User-Agent:

Paste one single-line User-Agent string, e.g. a crawler or browser UA.

Fallback GET on 405:

Only applies when Live request method is HEAD.

Follow redirects:

Off inspects only the first response from the target URL.

Max redirect hops:

Range: 0-12 hops; use 0 for first response only.

Timeout (seconds):

Range: 2-40 seconds per hop.

Accept-Encoding:

Accepted: browser default, br/gzip/deflate, gzip/deflate, or identity.

Include deprecated checks:

Flags X-XSS-Protection, Expect-CT, Feature-Policy, and HPKP.

Extra request headers:

Add optional Header and Value pairs for the live probe.

Header:

Example: Accept-Language or X-Requested-With; restricted names are ignored.

Value:

Enter the exact value to send; leave blank only when testing empty headers.

Control	Status	Observed	Why it matters	Recommendation	Copy
{{ row.control }}	{{ row.status }}	{{ row.value }}	{{ row.why }}	{{ row.recommendation }}

Priority	Action	Evidence	Next step	Copy
{{ row.priority }}	{{ row.control }}	{{ row.value }}	{{ row.recommendation }}

Hop	Method	Status	Time	Policy signal	Route	Copy
{{ row.hop }}	{{ row.method }}	{{ row.status }}	{{ row.time }}	{{ row.signal }}	{{ row.route }}

Header	Class	Value	Copy
{{ row.header }}	{{ row.classification }}	{{ row.value }}

Directive	Observed	Interpretation	Copy
{{ row.directive }}	{{ row.value }}	{{ row.interpretation }}

Artifact	Value	Detail	Copy
{{ row.artifact }}	{{ row.value }}	{{ row.detail }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

HTTP response headers are small lines of metadata, but they often decide how a browser, cache, crawler, or API client handles a response after the status code arrives. A single page load can involve transport rules, script restrictions, cookie handling, cross-origin access, cache freshness, content-type trust, and redirect behavior before the user sees anything useful.

Header review matters because many web problems are invisible in the rendered page. A site can look normal while a redirect response skips HSTS, a cookie ships without SameSite, a shared cache misses Vary: Origin, or a permissive CSP quietly leaves script injection paths open. The header set is also route-specific: a homepage, login screen, static asset, API endpoint, error page, and CDN-generated redirect may each return different rules.

Common HTTP header review areas and why they matter
Review Area	What It Influences	Common Mistake
Transport	Whether browsers remember to use HTTPS and resist downgrade paths.	Checking only the final page while HTTPS redirects or error responses miss the same policy.
Browser execution	Which scripts, frames, content types, and browser features are allowed.	Treating a present header as safe even when the value is broad or obsolete.
State and sharing	How cookies, CORS, referrers, and cross-origin isolation behave.	Auditing a public route and assuming authenticated or personalized routes match it.
Caching	Whether browsers and intermediaries may store, reuse, or revalidate a response.	Adding freshness directives without considering private content, origin variation, or validators.

Some headers are defensive defaults that most browser-facing pages should carry. Others are contextual. A public image asset can use aggressive caching, while an account page usually needs stricter storage limits. A wildcard CORS response may be fine for intentionally public data and dangerous for personalized data. Strong header review therefore asks both questions: what did this response send, and does that match the response's job?

A header check is still a snapshot. It does not prove application logic, authentication, certificate trust, malware safety, or every route on the same host. It is best used as repeatable evidence for one observed request path, then compared across the important paths users and clients actually hit.

How to Use This Tool:

Use one target per run so the grade, redirect trail, header inventory, cache notes, and exports all describe the same observed request.

Enter one http or https URL in URL target. A missing scheme is treated as HTTPS, and extra pasted lines are ignored after the first usable URL.
Pick Analysis profile. Balanced fits ordinary web pages, Strict raises the bar for mature production hardening, and API profile avoids treating every missing browser-page control as equally severe.
Start with HEAD for a fast metadata check. Switch to GET if the server rejects HEAD, sends different headers by method, or needs a request closer to normal browser traffic. Keep Fallback GET on 405 on when HEAD is the first try.
Leave Follow redirects enabled when you care about the terminal response. Turn it off only when the first redirect response is the response you are auditing.
Adjust User-Agent profile, Accept-Encoding, timeout, hop cap, and extra request headers only when you need to reproduce a specific client view. Do not put secrets, bearer tokens, signed links, or private cookies in custom headers or URLs.
Run the check and fix setup errors before reading the score. Invalid URLs, timeouts, redirect caps, rejected methods, and ignored extra lines mean the evidence is incomplete or narrower than intended.
Read Hardening Scorecard and Priority Queue first, then use Hop Trail, Header Matrix, Cache Semantics, Header Posture Map, Wire Preview, and JSON when you need details for a handoff or regression record.

A clean first pass has the expected final status, no unexplained redirect stop, a first priority row you can act on, and request settings that match the client path you meant to test.

Interpreting Results:

The letter grade is a summary of checked rows under the selected profile. It helps compare runs, but it is not the audit finding by itself. A warning on one high-risk control can matter more than several passing rows on headers that are less relevant to the checked route.

HTTP header result cues and recommended follow-up checks
Result Cue	How to Read It	Follow-up Check
Fail	A required or high-value control is missing, invalid, or contradicted for the selected profile.	Start with rows marked Now, especially HSTS, CSP, MIME sniffing, framing, CORS, and response status issues.
Warn	The header may exist, but the value is weak, broad, incomplete, conflicting, or context-dependent.	Compare the value with the response type, cookie use, cache policy, and intended cross-origin behavior.
Info	The signal is useful context without being scored as a failure in the current profile.	Review it when the route is sensitive, strict hardening is the goal, or the same host has mixed page and API traffic.
Redirect drift	Intermediate responses may have different status, host, disclosure, HSTS, or CORS evidence than the final page.	Keep edge redirects, canonical URLs, error templates, and final responses aligned on baseline headers.
Cache conflict	Freshness, storage, validation, or variation rules may not match the sensitivity of the response.	Check whether the content is public, personalized, revalidated, immutable, or varied by request headers.

A strong score on a public landing page does not cover the login page, API responses, CDN error pages, or authenticated paths. A weak score on a static asset may also be less urgent than the same finding on a stateful page. Treat the scorecard as route evidence, then repeat the check wherever headers can be generated by a different application, proxy, CDN rule, or error handler.

The exported rows are useful for comparison only when the request viewpoint is stable. Method, user agent, custom headers, content encoding, redirect following, geography, cache state, and authentication can all change the returned headers.

Technical Details:

HTTP header hardening crosses several browser and intermediary mechanisms. Strict-Transport-Security teaches browsers to prefer HTTPS on future visits. Content-Security-Policy constrains script, frame, and resource loading behavior. X-Content-Type-Options: nosniff reduces content-type guessing. Cookie attributes influence whether state is sent over HTTPS, exposed to scripts, or sent in cross-site contexts. Cache directives tell browsers and shared caches whether a response can be stored, reused, or revalidated.

The final response normally carries the policy a client uses for the requested resource, so most hardening rows are based on that hop. Redirects still matter because users and scanners see them too. An HTTPS redirect that lacks HSTS, an edge response that reveals platform details, or a long redirect chain can weaken the overall evidence even when the terminal page looks cleaner.

Checked Control Areas

HTTP header checker control areas and scoring signals
Control Area	Signals Used	What Changes the Finding
Transport	Final HTTPS status, HSTS max-age, preload syntax, and HSTS continuity on HTTPS redirects.	Strict mode expects a longer HSTS lifetime than the balanced profile, and missing HSTS on HTTPS hops can raise redirect continuity findings.
Execution	CSP, `nosniff`, and framing protection through `X-Frame-Options` or CSP `frame-ancestors`.	Missing CSP, unsafe script allowances, missing MIME protection, or absent framing controls raise the severity.
Privacy and state	Referrer policy, Permissions-Policy, and observed `Set-Cookie` attributes.	Permissive referrer rules, broad browser feature access, or cookies missing `Secure`, `HttpOnly`, or `SameSite` reduce the result.
Isolation and sharing	COOP, COEP, CORP, Origin-Agent-Cluster, and CORS response headers.	Partial isolation, wildcard CORS, credential conflicts, and missing `Vary: Origin` on cacheable explicit-origin CORS responses can produce warnings or failures.
Caching	`Cache-Control`, validators, `Vary`, `Age`, `Expires`, and `Cache-Status`.	Missing policy, missing validators, or contradictory directives make stored responses harder to reason about.
Exposure debt	Common platform disclosure headers and optional checks for obsolete security headers.	Version banners, stack hints, `X-XSS-Protection`, `Expect-CT`, `Feature-Policy`, or HPKP headers add cleanup work.

Score and Grade Model

Informational rows are excluded from the headline percentage. Passing rows receive full credit, warning rows receive partial credit, and failing rows stay in the denominator with no credit.

score = \frac{P + 0.55 \times W}{P + W + F} \times 100

P is the count of passing rows, W is the count of warning rows, and F is the count of failing rows. Grades map to the rounded score as A at 94 and above, B at 84 to 93, C at 72 to 83, D at 58 to 71, and E below 58. For example, 10 passes, 4 warnings, and 2 failures produce (10 + 0.55 x 4) / 16 x 100, which rounds to 76 and displays as C.

Cache Classification Order

Cache classification order used for final response headers
Label	First Matching Signal	Practical Reading
no-store	`Cache-Control: no-store`	The response says it should not be stored by caches.
private	`private` without `no-store`	Browser storage may be allowed, but shared caches should not reuse it for others.
revalidate	`no-cache` or `must-revalidate`	Stored copies need origin validation before reuse.
immutable	`immutable`	The response claims it will not change during its freshness lifetime.
cacheable	Positive `max-age`	The response provides an explicit freshness lifetime.
unspecified	No matching cache directive	Caches may fall back to heuristics or surrounding defaults.

The live probe follows the selected method, redirect, timeout, user-agent, encoding, and extra-header choices from an external network position. It can show what that viewpoint received, but it cannot prove what a logged-in browser, another region, a warm CDN cache, or a different client will receive.

Privacy and Accuracy Notes:

The target URL and selected request options are sent to a live checking service because a browser alone cannot reliably fetch arbitrary response headers across origins. Extra request headers are sanitized, and restricted hop-by-hop names are ignored, but any value you provide can still be transmitted to the target server during the probe.

Do not check password-reset links, magic-login URLs, bearer-token URLs, private intranet hosts, signed download links, or endpoints you are not authorized to test. Use a non-secret test route that returns the same relevant headers when you need to verify a sensitive flow.

Some security decisions need separate evidence. Certificate validation, content scanning, authentication behavior, source-code defects, and full vulnerability testing are outside a response-header snapshot.

Worked Examples:

Production page before release

A team checks https://www.example.com/ with the Balanced profile, HEAD, and redirect following enabled. The final status is 200, the grade is B, and the first priority row says the HSTS lifetime is short. That is enough to assign a transport hardening fix, but it is not enough to claim the whole site is covered. The login page, account area, API base URL, and error templates should be checked separately.

API endpoint with CORS and caching

An API response returns Access-Control-Allow-Origin: https://app.example and Cache-Control: public, max-age=600. If the cache view does not show Vary: Origin, the CORS row can warn even though the allow-origin value is explicit. The response may vary by requester, so a shared cache needs the origin in the cache key or the cache policy needs to change.

HEAD blocked by the origin

A legacy endpoint returns 405 Method Not Allowed to HEAD. With fallback enabled, the check retries with GET and reports the GET-path headers. Keep that method in mind when comparing results with monitoring, browser captures, or release evidence.

Signed URL avoided

A one-time download link includes a secret token. Instead of pasting it, create a safe test URL that returns the same cache, cookie, and CORS behavior without granting access to private content. The header question can be answered without exposing the credential.

FAQ:

Does a high grade mean the site is secure?

No. It means the observed response had strong checked headers for the selected profile. Application logic, authentication, certificate trust, content safety, and untested routes still need separate review.

Why can two runs against the same URL differ?

Headers can vary by method, user agent, request headers, CDN edge, cache state, geography, authentication, and deployment timing. Keep request settings stable when comparing runs.

Should API responses carry the same headers as web pages?

Some controls still matter, especially transport, CORS, cache, status, and disclosure headers. Browser-page controls such as framing may be less central for pure APIs, which is why the API profile changes the severity of some findings.

Why does the checker care about redirects?

Redirects are real responses. They can reveal stack details, miss HSTS on HTTPS hops, return unexpected methods after a 303, or stop before the final destination when the hop cap is reached.

Why should I avoid secret URLs and headers?

A live check must send the target and selected request options outside your browser and to the target server. Secret-bearing URLs and headers can expose credentials or one-time access tokens during the test.

Glossary:

Final hop: The last response reached in the checked request path. Most header findings describe this response.
HSTS: HTTP Strict Transport Security, a policy that tells browsers to use HTTPS for future visits to the host.
CSP: Content Security Policy, a browser policy that restricts allowed scripts, frames, resource loads, and related behavior.
CORS: Cross-Origin Resource Sharing, the browser mechanism that decides whether another origin may read a response.
Validator: A response header such as ETag or Last-Modified that lets a cache ask whether stored content is still current.
Vary: A header that tells caches which request headers affect the selected response representation.
Preload: An HSTS option for domains that want browsers to know HTTPS is required before the first visit, after separate domain-wide readiness checks.

References:

RFC 9110: HTTP Semantics, IETF, June 2022.
RFC 9111: HTTP Caching, IETF, June 2022.
Strict-Transport-Security header, MDN Web Docs.
Content-Security-Policy header, MDN Web Docs.
Access-Control-Allow-Origin header, MDN Web Docs.
Cache-Control header, MDN Web Docs.
HTTP Security Response Headers Cheat Sheet, OWASP Cheat Sheet Series.