HTTP headers checker

What this tool shows

Before a page appears, the server sends a status code and a set of headers: what kind of response it is, how long to cache it, which security rules apply, which cookies to set and where to go next. Browsers hide this by default. The HTTP headers checker makes the request from LookupOwl's server, follows any redirects, and shows each hop's status, the IP that answered, how long it took and every header.

Use it to debug caching and CDN (content delivery network) behaviour, confirm that security headers are really being sent, find out why a URL redirects somewhere unexpected, or see what a crawler or API client gets without installing anything.

How to use it

1. Enter a URLType https://example.com/page or just example.com. A bare host is tried over HTTPS first, then over plain HTTP if HTTPS cannot be reached at all. Only public addresses on ports 80, 443, 8080 and 8443 are fetched.
2. Pick a methodIn More options, choose GET or HEAD. GET shows what a browser would receive. HEAD asks the server for the headers only, which is lighter for large files, though a few servers answer it differently. You can also switch off Follow redirects there to see just the first response. Either way, LookupOwl reads only the headers and never downloads the page.
3. Read each hopIf the URL redirects, every step appears with its own status and headers, ending at the final response. LookupOwl follows up to 10 redirects. For a closer look at chains and loops, use the redirect checker.

# The same check from a terminal
curl -sIL https://example.com
curl -s -o /dev/null -D - https://example.com

The headers worth knowing

LookupOwl also grades the final response on six security headers, weighted by importance: Content-Security-Policy 30 points, HSTS 25, frame protection 15, X-Content-Type-Options 15, Referrer-Policy 10 and Permissions-Policy 5. Each is rated good, ok, weak or missing, the total becomes a score out of 100, and the score becomes a grade from A+ (97 and up) down to F (under 40). Treat the grade as a checklist rather than a verdict, because a header can be absent for a good reason. If the last response is a redirect, for example because you switched off Follow redirects, there is no grade: its headers belong to the page it points to.

The result also summarises caching (max-age, no-store, validators), lists each cookie's name and flags, and names the server software or CDN when the headers give it away. The Cookies tab never shows cookie values, but the raw Set-Cookie lines do, so skim a result before you paste it into a public thread.

• Status classes. 2xx means success, 3xx a redirect, 4xx a problem with the request (404 missing, 403 forbidden, 429 too many requests) and 5xx a server failure (500, 502, 503, 504).
• Protocol. Each hop says it was fetched over HTTP/1.1, because that is the only version LookupOwl speaks, so it is not a sign of what the site supports. When the final response offers HTTP/2 or HTTP/3 in its Alt-Svc header, the answer at the top says so. The questions below say more.
• Timing. Each hop's time runs from the start of the request to the arrival of the response headers, so it includes the DNS lookup, the connection and the TLS handshake. It is one measurement from one place: a hint, not a benchmark.

Problems you can diagnose

• Stale content after a deploy. Look at Cache-Control, Age and ETag. A CDN may still hold the old copy.
• HSTS missing. Without it, a first visit over HTTP can be intercepted before the redirect to HTTPS.
• Cookies without flags. Session cookies that lack Secure or HttpOnly are easier to steal or leak.
• A different result from my browser. The request comes from LookupOwl's server, not your device, and sites may serve different content to different clients or countries.
• 403 or 429 from the site. Some sites block automated requests. That is the site's choice, and it is useful to know.
• An error instead of headers. The checker verifies certificates, so an https:// address whose certificate fails shows an error, not headers. A bare host is retried over plain HTTP, and the result says what failed. Use the SSL checker to see what is wrong.
• Cannot connect. The address may be blocked (private or loopback), on a port other than 80, 443, 8080 or 8443, or the server may be down. Check its DNS records.

How the fetch works

LookupOwl looks up the hostname once, checks that every address it returns is public, then connects to that exact IP so DNS cannot be swapped underneath it. It sends one GET or HEAD request per hop, with a user agent that names LookupOwl and points to the About page, and follows redirects itself, re-checking each new host. It reads the headers and hangs up, so no page is downloaded. Requests to private, loopback or reserved addresses are refused. Fresh checks of any one server or domain are limited to 30 a minute across all callers, so the tool cannot be used to flood a site. Results are cached for two minutes, and Check again fetches a fresh one.

Standards

• RFC 9110: HTTP semantics, methods, status codes and header fields. RFC 9111: caching.
• RFC 9112: HTTP/1.1, the version LookupOwl speaks. RFC 9113 and RFC 9114: HTTP/2 and HTTP/3. RFC 7838: Alt-Svc.
• RFC 6797: HTTP Strict Transport Security. RFC 6265: cookies.
• IANA HTTP Field Name Registry: the list of registered header names.