Reading HTTP Response Headers

Every HTTP response carries a set of headers alongside the actual page content, metadata about the response itself rather than the content of the page. Browsers read these constantly to decide how to cache a page, what type of content they are receiving, and how to handle redirects, but a person can read them directly too, and they often reveal useful, sometimes unintended, detail about how a server is set up.

• content-type tells the browser what kind of content is being sent, such as text/html or application/json, so it knows how to interpret it.
• content-encoding shows whether the response was compressed, commonly with gzip or brotli, before being sent, which reduces transfer size.
• cache-control tells browsers and intermediate caches how long a response can be reused before checking back with the server.
• server sometimes names the software handling the request, though many sites deliberately omit or generalize this to avoid revealing specifics to anyone probing for known vulnerabilities.
• set-cookie, when present, tells the browser to store a cookie, commonly used for sessions, preferences or tracking.

Headers like server, x-powered-by, or a distinctive combination of cookie names can hint at the underlying technology behind a site, sometimes down to the specific framework or hosting provider. This is genuinely useful for understanding how a competitor's site is put together, but it cuts both ways: the same information helps anyone looking for known weaknesses in a specific, identifiable piece of software, which is why some teams deliberately strip or generalize these headers in production.

curl -I https://example.com

The -I flag requests headers only, without downloading the actual page body, which is a fast way to check what a server returns before deciding whether to fetch the whole thing. If the response is a redirect, curl will show the location header pointing at the next URL, and following the chain by hand this way is a useful habit before assuming a fuller tool is necessary.

The HTTP Headers tool does the same job as the curl command above, returning every header a target actually sent back along with the status code, HTTP version and any redirects that were followed to get there, without needing a terminal or any command line familiarity at all.