Network Tools Updated 2026-05-25

HTTP Headers Inspector — what the wire actually returned, not what the browser rendered

A practical guide to PortJar's HTTP Headers Inspector — when to use it instead of devtools, how to read the redirect chain, and which security headers are worth flagging when they're missing.

The browser is the worst place to verify what an HTTP endpoint actually returns. It silently follows redirects, caches responses, holds onto a previous TLS session, and lets a service worker rewrite the answer before you ever see it. When a deployment looks wrong and you need to confirm what the server sent, you want a tool that fetches the URL fresh, follows every hop, and shows you the raw response headers without rendering anything. That is what PortJar’s HTTP Headers Inspector is for.

What the tool does

The inspector sends a GET request from a PortJar server, follows every 3xx redirect to completion, and returns the headers, status line, and timing for each hop. The final response is annotated with the security headers it found — HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — and which ones are missing. The body is not rendered; the point is to see exactly what the wire delivered, in the order it was delivered.

Because the fetch originates from PortJar rather than your browser, there is no shared cookie jar, no shared TLS session, no extension altering the response. The answer is what a fresh client would have seen on the first request. That is the answer you want when somebody says “but it works for me.”

How to use it

Open portjar.com/tools/http-headers, paste the full URL including the scheme, and run. The result lays out each hop in the chain — the requested URL, the status code, the response headers — followed by the final response with the security-header summary. Send the URL to a teammate and they’ll see the exact same chain when they load it.

When you’d reach for it

  • Verifying a deploy actually shipped. After a release, fetching the entrypoint and reading ETag, Last-Modified, or a custom X-Build-Id header is the fastest way to confirm the new artifact is being served. A stale value means a CDN cache, a stuck worker, or a misrouted backend.
  • Confirming HSTS is set correctly before submitting to the preload list. A missing includeSubDomains or preload directive is invisible in a browser until preload submission fails. The inspector shows you the exact Strict-Transport-Security header value in one shot.
  • Debugging a “the site loads but assets are blocked” report. Read the Content-Security-Policy header on the document response. Nine times out of ten the CSP was tightened by a recent change and a vendor’s script no longer matches an allowed source.
  • Reproducing a redirect bug a client can’t show on screen-share. The inspector’s hop list shows whether a redirect is 301 or 302, whether it strips cookies, and whether it changes scheme. Browser devtools obscure most of this once the chain has resolved.
  • Confirming a vanity domain or vendor URL actually lands on your origin. Fetching the vanity through the inspector exposes every hop — including the ones the vendor adds for tracking.

What to make of the output

Read the chain top to bottom. Each hop’s status code tells you whether the redirect is permanent (301, 308) or temporary (302, 303, 307) — that distinction matters for SEO and for how downstream caches handle the response. A chain longer than two hops on a production endpoint deserves a second look; redirect chains compound latency and waste request budget.

Look at the final response’s Content-Type, Cache-Control, and Set-Cookie headers. A document served as text/plain instead of text/html is almost always a misconfigured origin or a missing MIME map. A Cache-Control: no-store on a page that should be cached by the CDN means the CDN is doing nothing for you. A Set-Cookie without Secure or HttpOnly is a finding to log.

The security-header summary at the bottom is a quick triage list. Missing HSTS on a production site is almost always wrong. Missing CSP is common but worth flagging. Missing X-Content-Type-Options: nosniff is trivial to fix and worth doing. Pair the verdict with the PortJar guide on port 443 being open but the site not loading when the headers don’t explain a user-facing failure.

If the chain ends in a 5xx, the headers themselves are diagnostic — look at the Server, Via, and any X-Request-Id values to figure out which layer responded.

For environments where header policy, redirect hygiene, and CDN behaviour need to stay consistent across many sites, Stack Harbor handles that as part of Environment Management as a Service.

Book consult