| 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 }} |
{{ curlCommand }}
{{ wirePreview }}
HTTP response headers are the short rules attached to a web response. They tell browsers and intermediaries whether a page should be cached, whether another origin may read it, whether a cookie is protected, and whether a browser should keep using HTTPS. A site can still look normal while these rules drift across redirects, CDN edges, error templates, and API routes.
This checker turns one live request into a readable header audit. It can start with HEAD or GET, follow redirects, retry a rejected HEAD request as GET, and then score the observed response across transport, execution, privacy, isolation, caching, and disclosure concerns. The result is organized into Hardening Scorecard, Priority Queue, Hop Trail, Header Matrix, Cache Semantics, Header Posture Map, Wire Preview, and JSON.
That makes it useful before a launch, after a CDN or reverse-proxy change, during cache debugging, or when browser requests behave differently from expectations. It is also a practical way to confirm whether a redirect path quietly drops Strict-Transport-Security, whether a CORS response is broader than intended, or whether cookie flags are missing on the actual response that reaches clients.
Use caution with inputs. The page keeps the current URL and settings in the address bar for shareable state, and the live request is performed by a helper service rather than by the browser tab itself. Any custom request headers you add are sent as part of that probe. Do not paste signed URLs, password-reset links, session-bound endpoints, or any target you are not authorized to inspect.
The page is intentionally single-target. If you paste several lines, it keeps only the first non-empty one and warns that the rest were ignored. If the scheme is missing, it assumes https://. Only HTTP and HTTPS targets are accepted. Advanced settings let you change the analysis profile, request method, redirect following, 405 fallback, redirect ceiling, per-hop timeout, accepted encodings, user-agent profile, and up to twelve extra request headers.
Method choice matters. Per RFC 9110, HEAD is the same as GET except the server must not send the response body, so it is a fast first pass when you mainly want metadata. Some sites do not expose the same behavior on HEAD, or they reject it entirely. That is why the checker can start with HEAD but retry the same hop with GET on 405 Method Not Allowed. If a redirect uses status 303, later hops switch to GET; otherwise the current method is kept.
| Profile | What it is for | What changes in the audit |
|---|---|---|
| Balanced | General website review | Uses the normal rule set, including a one-year HSTS expectation and standard page-facing framing guidance. |
| Strict | Hardened production posture | Raises the HSTS lifetime target to two years and treats several disclosure, cookie, and continuity issues more aggressively. |
| API | Endpoints that are not meant to render in a browser page | Keeps the main transport, CORS, cache, and cookie checks, but softens missing framing protection because many APIs are not embeddable documents. |
The scorecard covers more than a simple header listing. It checks HSTS and preload readiness, Content Security Policy, X-Content-Type-Options, framing protection, referrer leakage, Permissions-Policy, cross-origin isolation signals, CORS exposure, cookie flags, cache directives, fingerprint leakage, optional deprecated headers, redirect continuity, and final response status. Most of those checks read the final hop because that is the response clients ultimately use. Redirect continuity is different: it walks the full chain and looks for HTTPS hops missing HSTS or intermediate steps that still leak stack details.
How the page derives the headline grade
Info rows stay visible but do not change the grade. The letter bands are A at 94 and above, B at 84 to 93, C at 72 to 83, D at 58 to 71, and E below 58.
| Lane | Rows behind it | What the score describes |
|---|---|---|
| Transport | HSTS, preload, redirect continuity, final status | Whether the request path stays on a stable HTTPS track and reaches a usable terminal response. |
| Execution | CSP, nosniff, framing | How tightly the final response controls script execution, MIME handling, and embedding. |
| Privacy | Referrer policy, permissions policy, cookies | How much browsing context and state can leak or be overexposed. |
| Isolation | COOP, COEP, CORP, OAC, CORS | How clearly the response separates itself from other origins and cross-origin readers. |
| Caching | Cache policy and validators | Whether freshness and reuse rules are explicit enough to debug and trust. |
| Exposure | Fingerprint leakage and deprecated headers | How much avoidable implementation detail or legacy debt still reaches the client. |
The cache view goes deeper than a raw Cache-Control string. It breaks directives into readable lines and supplements them with validators and cache metadata such as ETag, Last-Modified, Age, Expires, Cache-Status, Vary, and Pragma. That matters because RFC 9111 treats no-store, no-cache, private, must-revalidate, and freshness values differently, and because origin-specific CORS responses can become unsafe in shared caches if Vary: Origin is missing.
The checker is still a header auditor, not a complete trust audit. It tells you what the helper service observed from its network position, with the request headers and method you chose. That can differ from what your own browser, geography, or authenticated session would see. A strong grade therefore means the observed HTTP metadata looks disciplined. It does not certify certificate trust, page content, form behavior, business logic, or every edge case on the site.
Start with the defaults unless you already know the response is method-sensitive. A balanced profile, HEAD, redirect following on, 405 fallback on, and the default timeout give a fast first pass for most sites. Read the summary badge row first, then open Hardening Scorecard and Priority Queue before drilling into the raw headers.
The best interpretation flow is simple. Use Hardening Scorecard to see which controls passed, failed, or only partly met expectations. Use Priority Queue to translate those findings into action order. Use Hop Trail when you suspect edge drift, host rewrites, or partial HTTPS migration. Then use Header Matrix and Cache Semantics to inspect the exact terminal response that fed the final judgment.
HEAD to GET when a target rejects HEAD, when a framework behaves differently on metadata-only requests, or when you want a closer match to normal browser fetches.Be deliberate about redirect following. Leave it on when you want to know what a normal user finally gets. Turn it off only when the first redirect response is the thing you need to audit, such as checking whether a bare domain immediately upgrades to HTTPS or whether the first hop already sends HSTS.
The wire tools are useful for handoff. Wire Preview shows the final status line and final-hop headers in a terminal-like block, and it generates a matching curl command for the main request options that affect transport behavior. JSON is the fuller export when someone else needs the raw chain, the request settings, the score rows, and the posture-map axes in one file.
Treat weak findings in context instead of chasing a single badge. Missing HSTS on a redirect hop is different from missing HSTS on the final HTTPS response. A wildcard Access-Control-Allow-Origin may be acceptable for a public static asset but not for a personalized API. A private cache policy may be correct for user-specific content, while the same directive on a versioned static file would deserve a second look.
HEAD for the first pass unless you are checking an API or a method-sensitive route.The headline grade is a compact summary of many rows, not a replacement for them. An A or B usually means the observed response is carrying the main modern controls with few obvious contradictions. A lower grade means the page saw missing, weak, or conflicting rules. The most important habit is to read the specific rows that failed rather than arguing with the letter.
Pass, Warn, Fail, and Info do different jobs. A fail usually means a missing control, a broken combination, or a response that never reached a stable endpoint. A warning means the signal exists but is broad, weak, incomplete, or risky in context. An info row marks a control that is optional or situational for the current request. The Priority Queue turns those same rows into Now, Soon, and Later so you can separate urgent transport and script-safety fixes from cleanup work.
| Label | Meaning in this checker |
|---|---|
| no-store | The final response explicitly tells caches not to store it. |
| private | The response is intended for a single-user cache rather than a shared intermediary. |
| revalidate | The response can be stored, but reuse depends on validation rules such as no-cache or must-revalidate. |
| immutable | The response declares that it should not change during its freshness window. |
| cacheable | A positive freshness lifetime was detected. |
| unspecified | No strong terminal cache classification was derived from the observed headers. |
The path view matters as much as the terminal view when redirects are present. Hop Trail shows method, status, timing, quick policy signals, and routing for each step. If the final page looks clean but an earlier HTTPS hop omits HSTS or still leaks Server and Via, the chain is telling you where the hardening gap actually lives.
The posture chart is best read as balance, not as certification. A low Transport score means the path or final status is unstable. A low Execution score points to script, MIME, or framing weakness. A low Privacy or Isolation score suggests that cross-origin or cookie boundaries need attention. A low Exposure score usually means version leakage or legacy headers are still visible.
Limit notes deserve respect. If the run stopped because of timeout, max_redirects, or redirects intentionally left unfollowed, the visible result is partial by definition. In those cases the tool is still useful, but it is answering a narrower question than "what does the final production response look like?"
Suppose http://example.test returns a 301 to https://www.example.test, and the final HTTPS response includes long-lived HSTS, a restrictive CSP, nosniff, a clear referrer policy, and no obvious stack headers. The scorecard would likely show mostly passes, the redirect continuity row would stay green, and the posture map would be strongest in Transport and Execution.
Now imagine an API responds with Access-Control-Allow-Origin: https://app.example and Cache-Control: public, max-age=600, but does not send Vary: Origin. The response is not necessarily broken in a browser, but shared caches can mix decisions across callers. The checker would flag the CORS exposure surface because the access rule varies by origin while the cache key does not say so clearly enough.
If the final response sets cookies without Secure, HttpOnly, or SameSite, the privacy lane drops quickly even when the rest of the page looks modern. In strict mode the checker treats missing secure cookie flags more harshly, which is useful when you are reviewing an authenticated path rather than a static brochure page.
Consider a path where the final page is tidy but one earlier redirect still exposes Server and Via headers or misses HSTS on an HTTPS hop. The final page alone would not reveal that gap. Hop Trail and the redirect continuity row make that drift visible so you can fix the edge response instead of only polishing the application origin.
It is designed as a single-target checker. Extra lines are discarded so one run always maps to one clear result set and one shareable request state.
The live request is performed by a helper service from its own network position. Redirect behavior, geolocation, edge routing, user-agent choice, request headers, and authentication context can all change what that vantage point receives.
It reproduces the main request shape, including method, redirect following, timeout, encoding preference, user-agent, and extra headers. The full audit still includes redirect analysis, score logic, posture-map grouping, and export structure that go beyond a single terminal command.
No. It means the observed HTTP response metadata looks comparatively disciplined. It does not prove the certificate chain, page code, input handling, authentication flow, or server-side logic are safe.
Enable them when you are cleaning up older estates or comparing legacy behavior across environments. They help surface obsolete headers such as X-XSS-Protection, Expect-CT, and HPKP-related fields that can add noise without providing modern protection.
No. The checker is aimed at response headers and their meaning. Use a certificate-focused checker when the real question is trust chain validity, expiry, hostname matching, or revocation posture.
ETag or Last-Modified that helps caches and clients revalidate a stored response.*.Server or X-Powered-By, that reveal implementation detail to clients and scanners.