HTTP Headers Explained: How to Read Them Like a Developer

When you visit a website, a lot more is exchanged than just the page you see. Behind the scenes, your browser and the website's server pass each other a stack of short notes. Those notes are called HTTP headers, and once you know how to read them, you can learn a surprising amount about any site, how it's hosted, how fast it should feel, and whether its security is set up properly.

Don't worry, it's simpler than it sounds. Let's look at what these headers are, then read some real ones together.

What HTTP headers are (in plain English)

Think of a website request like ordering a package. You (the browser) send a slip saying what you want and a few preferences. The warehouse (the server) sends the package back with a label describing what's inside and how to handle it. Those slips and labels are HTTP headers, small lines of Name: value text attached to every request and response on the web.

HTTP itself is just the language browsers and servers use to talk, short for HyperText Transfer Protocol (MDN HTTP overview). Headers are the metadata that travels alongside the actual content. You never see them in a normal browser window, but they're always there.

A single header looks like this:

That one tells the browser "what I'm sending you is an HTML web page, encoded in UTF-8." There are dozens of standard headers, all catalogued in the MDN HTTP headers reference.

Request headers vs response headers

There are two directions, and it helps to keep them straight.

1. Request headers go from your browser to the server. They say things like which page you want, what languages you read, and which browser you're using (the User-Agent).
2. Response headers come back from the server to your browser. They describe the answer: the content type, caching rules, security policies, and clues about the server software.

For auditing a website, response headers are the interesting ones. They're what the server chooses to tell the world, and they're what we'll focus on below.

Useful response headers for an audit

Here's a quick reference table, then a closer look at the headers worth knowing. All of these are documented in the MDN HTTP headers reference.

Server

The Server header names the web server software, for example nginx or Apache. It's a fast way to see what's serving the site. Many hosts trim or hide this value on purpose, which is fine, more on that below.

X-Powered-By

This one often reveals the underlying technology, such as PHP/8.2 or Express. Handy for curiosity, but the OWASP HTTP Headers Cheat Sheet recommends removing it, because advertising your exact stack and version makes life easier for attackers.

Cache-Control

Cache-Control is the page's storage instruction. It tells browsers and intermediate caches how long they're allowed to reuse a copy before checking back, for example max-age=3600 means "fine to reuse for one hour." Good caching is one of the biggest free speed wins a site can have.

Content-Encoding

When you see Content-Encoding: gzip or br (Brotli), the server compressed the content before sending it. That means smaller transfers and faster loads. If a large text-based page has no compression header, that's a performance flag worth raising.

Strict-Transport-Security

Often shortened to HSTS, this header tells the browser "from now on, only ever talk to me over HTTPS." It's a strong protection against downgrade attacks, and OWASP lists it among the security headers every site should set (OWASP HTTP Headers Cheat Sheet).

Content-Security-Policy

CSP is a rulebook for what content the page may load and from where. Done well, it's one of the most effective defenses against cross-site scripting (where an attacker sneaks malicious code into a page). It can be tricky to configure, so its presence is usually a sign of a security-conscious team (OWASP HTTP Headers Cheat Sheet).

Via

The Via header is added by proxies and content delivery networks (CDNs) as the response passes through them. If you see it, the site is likely sitting behind a caching layer or CDN rather than serving you directly from the origin server.

Server-Timing

Server-Timing lets a server share performance numbers, like how long a database query took, directly in the headers so developer tools can display them. You won't see it everywhere, but when present it's gold for diagnosing slow pages.

Which headers you should not over-trust

Here's the part many beginners miss: headers can be edited, removed, or faked by whoever runs the server. So treat the descriptive ones as hints, not proof.

1. Server and X-Powered-By are the usual suspects. A site can blank them out or even set them to a misleading value. A missing Server header doesn't mean "no server," it usually means the admin chose to hide it. In fact, OWASP recommends minimizing or removing these information-disclosure headers (OWASP HTTP Headers Cheat Sheet).
2. Version numbers in those headers may be stripped or stale, so don't assume they're accurate.

The trustworthy headers are the behavioral ones, Cache-Control, Content-Encoding, Strict-Transport-Security, Content-Security-Policy, because the browser actually enforces them. If they're present, they're doing something real.

Reading headers manually with curl -I

You don't need fancy software to see headers. curl is a command-line tool built into macOS and Linux (and easy to install on Windows). The -I flag asks only for the headers, not the whole page.

Try this in a terminal:

You'll get something like:

Let's read it line by line:

1. HTTP/2 200 — the protocol version (HTTP/2) and the status code. 200 means success.
2. content-type — it's an HTML page in UTF-8.
3. server — nginx is serving it.
4. cache-control — browsers may reuse it for 3600 seconds (one hour).
5. content-encoding — it was gzip-compressed, good for speed.
6. strict-transport-security — HTTPS is enforced for the next year (31,536,000 seconds).

A couple of useful variations:

The extra -L tells curl to follow redirects, so you can see whether a site bounces you from http:// to https:// or from a bare domain to www. Each hop prints its own header block.

That's genuinely all you need to inspect any public website's response headers by hand.

FAQ

Are HTTP headers visible to normal visitors?

Not in the page itself. But anyone can see response headers using browser developer tools (the Network tab) or a command like curl -I. They aren't secret, they're just hidden from the normal view.

Is it safe to remove the Server and X-Powered-By headers?

Yes, and it's often recommended. Removing them reveals less about your stack to potential attackers, which OWASP encourages (OWASP HTTP Headers Cheat Sheet). It won't break your site.

What's the difference between Cache-Control and Content-Encoding?

Cache-Control decides how long a copy can be reused; Content-Encoding decides how the content is compressed for transfer. One is about storage time, the other about transfer size, and a fast site usually uses both.

Why do some sites show a Via header and others don't?

A Via header is added by proxies and CDNs. If you see it, the response traveled through a caching layer; if you don't, you're likely reaching the origin server more directly.

Do I need to install anything to check headers?

On macOS and most Linux systems, curl is already installed. On Windows it ships with recent versions, or you can use a browser's developer tools, no install required. For a no-terminal option, an online HTTP header checker does it in your browser.

Can a header lie about what software a site runs?

Yes. Descriptive headers like Server and X-Powered-By can be edited, faked, or removed, so treat them as hints. Behavioral headers that the browser enforces are far more reliable.

Check headers automatically

Reading headers by hand is a great skill, but you don't have to do it one curl command at a time. Our free HTTP header checker fetches every response header for any URL, highlights the security and caching ones, and explains them in plain language, so you can audit a site in seconds. Paste in a domain and check its headers automatically.