HTTP Header Inspector

Request a live URL, read the headers it serves, and see the problems in them named.

Secure server processingWeb & SEOWorkingNo account needed

What this tool does

HTTP Header Inspector hands one URL to the OmniKitly processing service, which requests it and returns the address the response finally came from, its HTTP status and every header that arrived above the body. The page then reads that response itself and prints a verdict line — the status, how many headers came back, how many errors and how many warnings were found, and a one-word grade of Solid, Fair, Weak or Needs fixing — followed by a table of every header while the List every header box stays ticked, and then whichever of the Findings, Already good and Notes lists have something in them.

Those findings go well past a presence check. Strict-Transport-Security is read for its max-age, so anything under six months is called short and a preload flag without includeSubDomains is called ineligible. A CSP is split into directives, which puts 'unsafe-inline', 'unsafe-eval' and an absent script-src each on their own line. Cache-Control public alongside Set-Cookie is raised as an error rather than a note, because a shared cache can then hand one visitor's cookie to another. Cookies are read for Secure, HttpOnly and SameSite, a wildcard Access-Control-Allow-Origin beside Allow-Credentials is flagged, a text response with no Content-Encoding is flagged, and a Server or X-Powered-By line carrying a version number is reported as something to trim.

The request itself is a single plain GET issued from the service's own address. It carries the OmniKitly user agent and nothing of yours — no cookie, no bearer token, no basic-auth header — so an address behind a login answers with its sign-in redirect or a 401, and those are the response headers you get graded. Up to five redirects are followed, and every hop is resolved and re-checked before it is called, but only the last response is analysed. Fifteen seconds of silence ends an attempt, and the body is capped at 64 KB and then thrown away, so nothing in the page's own markup is examined.

Three limits are worth holding before you rely on a run. The headers arrive as a JSON object keyed by name, so a name that appeared twice survives only once — several Set-Cookie lines collapse into one, and the missing-flag check then looks at that single cookie. The request also leaves a data centre rather than your browser, so a CDN, WAF or bot rule may meet it with a challenge page, a flat 403 or a different cache state than it gives you, which makes a surprising result a question about your edge as much as an answer about your site. And the work happens on the service: the URL travels there over an encrypted connection and is kept in the job record, which a periodic sweep deletes together with the headers.json the run produced once the retention window — six hours unless it has been changed — has passed.

How to use it

  1. Enter one full URL. A scheme is required, so https://example.com/pricing rather than a bare domain, and the exact path matters because caching and cookie rules are usually set per route rather than per site.
  2. Run it. One GET leaves the service, up to five redirects are followed, and a host that stays silent for fifteen seconds is given up on rather than left hanging.
  3. Read the verdict line, then the findings. It carries the status, the header count, the error and warning totals and the grade. An error marks a response already broken or unsafe; warnings and notes are everything worth a second look.
  4. Keep headers.json if you plan to compare. The download holds the raw response as the service saw it, together with a six-header security score, which turns a before-and-after check across a deploy into a file diff rather than a memory test.

Processing & privacy

Secure server processing. This operation requires temporary server processing.

Common use cases

A caching rule that has not taken effect

Read the Cache-Control the live route actually serves, next to any Age or s-maxage an edge added, instead of trusting the rule as it was written.

Confirming a security header shipped

Configuration and reality drift apart. A policy a proxy quietly stripped, or an HSTS max-age still set to the sixty seconds you used while testing, both surface in the findings.

An API the browser refuses to read

Access-Control-Allow-Origin and its companions come back exactly as sent, and a wildcard origin combined with credentials is called out as something browsers reject outright.

A response that names its stack

Server, X-Powered-By and the ASP.NET version headers are each reported when they carry a version number, which is usually the cheapest thing on the list to fix.

Questions

Where does the address I type end up?
On the processing service. A page in your browser is not allowed to read another origin's response headers, so the address goes to the OmniKitly processing service over an encrypted connection and the request is made from that machine. It sits in the job row until the sweep removes the row and the headers.json together.
Can I paste the output of curl -I instead of a URL?
Not on this page. Whatever sits in the box is sent to the service as the address to request, so a pasted block of headers comes back refused as an invalid URL. The Load sample button fills the box with exactly such a block, and it is rejected the same way — replace it with a real address before running.
What does the grade mean?
It counts findings rather than headers. Any error at all makes it Needs fixing, more than four warnings make it Weak, one to four make it Fair, and a response with neither is Solid. The separate score out of six for the named security headers appears only inside the downloaded headers.json.
Does the List every header checkbox change what is checked?
No, only what is shown. Unchecking it removes the header table from the report on screen and leaves the findings in place, while the text behind Copy output and the headers.json download still list every header that arrived.
Why do these differ from my browser's network panel?
The request arrives from the service's address with its own user agent and no session of yours, so an edge rule may route it somewhere else. Cache-related headers in particular describe that request, not the one your browser made.
Does it show each hop of a redirect?
No. The hops are followed but only the final response is reported. Reach for Redirect Checker when the chain itself is the question, since that one returns every hop with its status and Location.
Can I inspect localhost, staging or an intranet host?
No. Every address a hostname resolves to is checked before a socket is opened, so loopback, private and link-local targets are turned away, as are .local, .internal, .lan, .home and .localhost names and any URL carrying a username and password.
What happens to a header sent more than once?
Only one copy survives the trip. Header names become the keys of a plain object, so a repeated name cannot be held twice — several Set-Cookie lines are the usual case. When the repeats matter, confirm them at the origin.

Related tools