HTTP Response Inspector

HTTP Response Inspector

This tool makes a real HTTP request to a URL and shows you exactly what came back: the status code, the final URL after any redirects, every response header, the technologies those headers reveal, and how long the request took. It is the browser DevTools "Network" tab as a shareable, server-side check.

What it shows

• Status code — 200 OK, a 3xx redirect, 401/403 auth walls, 404 not found, or a 5xx server error. The number is the fastest summary of what happened.
• Final URL — because redirects are followed and re-validated hop by hop, you see where the URL actually lands. This is how you catch an HTTP→HTTPS upgrade, a www/non-www canonicalisation, or an unexpected redirect to a different host.
• Every response header — not just the security subset, but the full set: caching directives, content type, cookies, CDN markers and framework fingerprints.
• Detected technologies — inferred conservatively from headers alone (Server, X-Powered-By, X-Generator, CDN markers like CF-Ray or X-Vercel-ID). Header-based only, so it never guesses beyond what the server actually advertises.
• Timing — total round-trip time for the request, a rough health and latency signal.

Why "live" and server-side matters

Fetching from the server, rather than pasting headers, means you see what a fresh, uncached client receives — including anything a CDN or reverse proxy adds or strips in front of your origin. That is frequently where the surprise lives: a header you set that never reaches the client, or a redirect you did not know was there.

Worked example

Request http://example.com and you may see a 301 to https://example.com, then a 200. The final URL confirms the HTTPS upgrade works; the Strict-Transport-Security header (or its absence) on the final response tells you whether the upgrade is enforced for next time.

The security angle

Headers are a reconnaissance goldmine and a hardening checklist at once. A verbose Server: Apache/2.4.29 (Ubuntu) or X-Powered-By: PHP/7.2 hands an attacker your exact stack and version — information disclosure worth removing. The redirect chain reveals whether HTTP is properly upgraded to HTTPS. And the presence or absence of security headers on the final response is what actually protects users.

Common mistakes

• Checking the first response instead of the final one — headers on a 301 are not the headers your users get.
• Leaving version numbers in Server/X-Powered-By — quiet but real information disclosure.
• Assuming your origin's headers reach the client — a CDN in front may rewrite them.