HTTP header & redirect checker.

Check response headers, follow the redirect chain hop by hop, see where the time goes on each request, and get a security headers review in plain English. Fetched from this server, so you see what a client really goes through.

About this tool

This server fetches the URL you give it with redirects switched off, so each hop in a chain is its own request on its own connection. For every hop it records how long DNS resolution, the TCP connect, the TLS handshake, the wait for the first byte and the body download took, then follows the Location header and does it again, up to ten times. The body is read (up to 2 MB) so the download phase is real, but it is discarded and nothing is stored. The request is sent with a browser-like Accept and Accept-Encoding so the server behaves as it would for a real visitor.

HTTP header checker

The final response headers table shows Content-Type, Cache-Control, Server, Set-Cookie, Vary and everything else the origin or CDN added, exactly as sent, with nothing normalised. Compare it with what your application thinks it is sending: the gap is usually a proxy or CDN rewriting Cache-Control, stripping a custom header, or adding its own Server line. For what the browser sends in the other direction, use the request header checker.

Redirect checker

The redirect chain lists every hop with its status code (301, 302, 307 or 308), its Location header and how long it took. Three hops to reach a page is three round trips your visitors pay for before the first byte of content, and each one is a place for a mixed-content or cookie bug to hide. The chain you want for a canonical site is one hop: http:// anything straight to the final https:// URL. Which code to use for each case is in 301 vs 302 vs 307 vs 308.

Security headers checker

The graded scorecard looks at the final response for Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy, plus version leakage in Server and X-Powered-By and the Secure, HttpOnly and SameSite flags on every cookie set along the chain. Each line says what was found and why it matters rather than just red or green. The two most often missing on otherwise well-run sites are CSP and HSTS; a CSP in report-only mode is a safe first step. The header-by-header explanation and a starting configuration are in HTTP security headers explained, and the domain health checker folds this grade into a whole-domain report.

Response time and TTFB test

The timing bar on each hop splits the request into DNS, connect, TLS, first byte and download. A long first-byte segment is the server thinking (slow application code, a cold cache, a database call); a long TLS segment is a distant edge or a server without session resumption; a long download on a small page is an uncompressed body. Because the fetch comes from this server, the numbers are one vantage point, not your users' experience, but the proportions between the phases are what tell you where to look.

Common findings

Examples

From the command line

curl "kirkdiamond.com/tools/http?url=example.com" or add &format=json for the full structured report, and &method=HEAD to skip the body. Only public hosts can be fetched.

Every parameter, the JSON field names, rate limits and ready-made CI checks are in the API and curl reference.