How to Read a Website's HTTP Response Headers

A website's HTTP response headers are the metadata a server sends with every page — and they reveal a great deal before you read a single word of the page itself: the server software, the CDN delivering it, how it caches content, what cookies it sets, and how seriously it takes security. The fastest way to see them is the DevTools Network tab (click the document request and read Response Headers) or a single terminal command: curl -I https://example.com. This guide explains what HTTP headers are, walks through the ones that matter most, and shows how to read them — tying it all back to technology detection, hosting and security.

It underpins much of the detection work in how to find out what technology a website uses and connects directly to HTTP security headers explained.

What HTTP headers are

When your browser requests a page, the server replies with two things: the body (the HTML, image or other content) and a set of headers — name-and-value pairs of metadata that describe the response. Headers travel ahead of the body and tell the browser how to handle what follows: what type of content it is, whether and how long it may be cached, which cookies to store, and what security rules to apply. There are request headers (sent by your browser) and response headers (sent back by the server); for investigating a site, the response headers are the interesting ones, because they describe how the server and its infrastructure deliver the page. They are, in effect, a compact technical summary of the site's delivery, written in a standard format.

How to view them: three ways

The DevTools Network tab. Open DevTools (F12), go to the Network tab, reload the page, and click the main document request (usually the first one, the HTML). The Response Headers section lists everything the server sent. This is the most visual method and lets you inspect any resource, not just the document.

curl -I. From a terminal, curl -I https://example.com performs a HEAD request and prints just the response headers — no body. It is fast, scriptable across many URLs, and shows exactly what the server returned without a browser in the way. (Use curl -sI to suppress the progress meter.)

Online header checkers. Several websites let you paste a URL and see its headers (and often grade the security ones). Convenient when you are not at a terminal, though they fetch from their own servers rather than your location, which can matter for geo-varying responses.

The headers that matter, by category

Headers fall into a few useful groups. Here is a reference table of the common ones and what each tells you.

Header	Category	What it reveals
Server	Detection	Web server software (e.g. nginx, Apache, cloudflare)
X-Powered-By	Detection	Backend tech/framework (e.g. PHP, Express, Next.js) — often removed
Content-Type	Content	MIME type and charset of the response
Cache-Control	Caching	How and how long the response may be cached
ETag	Caching	A version fingerprint for conditional requests
Age	Caching	How long a cached response has been stored (CDN/proxy)
CF-Ray	CDN	Cloudflare request identifier — signals Cloudflare
X-Cache	CDN	Cache HIT/MISS at a CDN/proxy (Fastly, CloudFront, Varnish)
Via	CDN/proxy	Proxies the response passed through
Set-Cookie	Cookies	Cookies the server is setting (session, tracking)
Strict-Transport-Security	Security	Forces HTTPS for future visits (HSTS)
Content-Security-Policy	Security	Restricts what resources can load
X-Content-Type-Options	Security	Stops MIME-type sniffing (nosniff)
X-Frame-Options	Security	Controls whether the page can be framed (clickjacking)

You will not see every header on every site, and that absence is itself informative.

Detection headers

Server and X-Powered-By are the classic technology tells. Server: nginx or Server: Apache names the web server; Server: cloudflare indicates Cloudflare is in front. X-Powered-By can reveal a backend — PHP/8.x, Express, sometimes Next.js. The caveat: both are commonly removed or changed by operators who do not want to advertise their stack, so their presence is a strong signal but their absence proves nothing. This is exactly the kind of corroboration the broader technology detection guide relies on.

CDN headers

CDN markers are some of the most reliable signals in the whole response. CF-Ray and Server: cloudflare mean Cloudflare; X-Amz-Cf-Id with a CloudFront Via means Amazon CloudFront; X-Served-By with a Varnish Via points to Fastly. The X-Cache: HIT/MISS and Age headers show the edge cache in action. These are hard to fake while genuinely using the service, which is why they anchor CDN detection and explain why an IP lookup often returns the CDN rather than the origin.

Caching headers

Cache-Control is the main caching directive — values like max-age=3600, no-store or public tell the browser and any proxies how the response may be cached and for how long. ETag is a version fingerprint that lets the browser ask "has this changed?" and get a cheap 304 Not Modified if not. Age (set by caches) shows how long a response has been sitting in a CDN or proxy. Together these reveal how a site manages performance and freshness — and good caching is a real speed win, as covered in performance work.

Cookies and security headers

Set-Cookie shows the cookies a server sets — session cookies, sometimes tracking ones — which is relevant to both functionality and privacy. The security headers are a quick read on a site's protective posture: Strict-Transport-Security enforces HTTPS, Content-Security-Policy restricts what can load, X-Content-Type-Options: nosniff and X-Frame-Options block specific attack classes. Their presence suggests a security-conscious operator; their absence is a gap. These deserve a closer look in their own right — see HTTP security headers explained.

A worked example

You run curl -sI https://shop.example and read the response. The first thing that jumps out is server: cloudflare and a cf-ray header — the site is behind Cloudflare, so you are seeing the edge, not the origin. cf-cache-status: HIT and an age: 240 tell you this response came from Cloudflare's cache, 240 seconds old. content-type: text/html; charset=UTF-8 confirms it is an HTML page. There is no x-powered-by, which is common and tells you nothing definitive about the backend. On the security side, you see strict-transport-security (good, HTTPS enforced) but no content-security-policy (a gap worth noting). In a single command you have learned the CDN, that caching is active, the content type, and a quick read on security posture — a lot of infrastructure insight from a few lines of metadata.

What headers reveal, and what they don't

Headers are a compact, high-value summary, but they have limits. They reveal the edge and delivery clearly — CDN, caching, content type, cookies, security policies — and they hint at the server and backend. What they do not reliably reveal is the origin behind a CDN (deliberately hidden), the full backend stack (often deduced from other signals), or anything the operator has chosen to strip. And because operators control them, headers can be customised, removed or even spoofed — a Server value can be edited, an X-Powered-By removed to hide the stack, or a misleading value set. So treat headers as strong evidence to corroborate, not as absolute proof in isolation. When headers and other signals (DNS, the page source, asset paths) agree, you can be confident; when they conflict, dig further.

Headers for hosting and security investigations

Reading headers is a building block for two bigger tasks. For hosting detection, the CDN headers and the resolved IP together tell you how a site is delivered and why the origin may be hidden — the full method is in how to find out where a website is hosted. For security review, the security headers are a fast first read on posture before any deeper testing, and grading them is a standard part of assessing a site. In both cases, the one-command curl -I (or a glance at the Network tab) is where you start, because it is quick, free, and surprisingly revealing. Headers are the connective tissue between "what is this site built and delivered with?" and "how well is it protected?".

Status codes and redirects travel with headers

While you are reading headers, do not ignore the status line that accompanies them, because it changes how you interpret everything else. A 200 OK means you are looking at the page you asked for. A 301 or 302 means a redirect — and the Location header tells you where to (for example HTTP redirecting to HTTPS, or a bare domain redirecting to www). A 304 Not Modified confirms a conditional request hit the cache via ETag or Last-Modified. A 403, 429 or 503 from a CDN can indicate rate-limiting or a security challenge rather than a genuine page. This matters in practice: if you run curl -I on a bare domain and get a 301 to the https://www version, the headers you see belong to the redirect, not the real page — so follow the redirect (curl -IL) to read the final response. Treating the status code and the headers as a pair, rather than reading headers in isolation, keeps your interpretation honest and explains otherwise confusing results.

Common mistakes when reading headers

A few errors recur. Reading only the homepage's headers — different resources (an image, an API response, a static asset) can carry different caching and CDN headers, so check more than one. Trusting X-Powered-By blindly — it is easy to remove or fake, so its absence is not evidence of absence. Ignoring the cache-status headers — X-Cache/cf-cache-status and Age tell you whether you are seeing cached or origin content, which changes how you interpret the rest. And forgetting headers can vary by location — a CDN may serve different headers to different regions, so an online checker's view may differ from yours. Keeping these in mind keeps your reading accurate.

The workflow

1. Fetch the headers with curl -sI https://example.com or the DevTools Network tab.
2. Scan the detection headers — Server, X-Powered-By — for technology hints.
3. Identify the CDN from CF-Ray, X-Cache, Via and friends.
4. Read the caching headers (Cache-Control, ETag, Age) for delivery behaviour.
5. Check the security headers, and corroborate everything with other signals.

Go deeper

• The detection it feeds: how to find out what technology a website uses.
• The security angle: HTTP security headers explained.
• Where the site lives: how to find out where a website is hosted.
• The CDN in front: how to tell if a website uses Cloudflare or another CDN.

Want a site's headers, stack, hosting and security read automatically? Analyse any site with StackOptic — one report, free, no sign-up.