How to Read HTTP Headers for Beginners (What Each Line Tells You)

Every time a browser asks for a web page, the server answers with two parts: the page itself, and a block of short notes about the page called HTTP headers. Visitors never see the notes, but they hold answers to many everyday questions. Is the page cached? Who runs the server? Is the site redirecting somewhere? Is a security setting missing? This guide teaches you to look at headers and read them, with no coding needed.

Step 1: Look at your headers

You have two easy options.

Option A: Use a free web tool

1. Open the HTTP Header Checker.
2. Enter your page address, such as https://www.example.com/.
3. Run the check and read the list.

A web tool tests from outside your network, which is useful because it shows what the rest of the world sees.

Option B: Use curl on your computer

If you are comfortable opening a terminal (Terminal on Mac, PowerShell or Command Prompt on Windows 10 and later), you can run:

curl -I https://www.example.com/

The -I flag asks for headers only. Add -L to follow redirects, and -s to hide the progress meter:

curl -sIL https://www.example.com/

You will see output like this:

HTTP/2 200
date: Wed, 08 Oct 2026 10:15:02 GMT
content-type: text/html; charset=UTF-8
server: nginx
cache-control: max-age=3600
strict-transport-security: max-age=31536000
x-content-type-options: nosniff

A third option is your browser. Open developer tools (F12 in most browsers), choose the Network tab, reload the page, click the first request, and look for Headers.

Step 2: Read the first line, the status

The first line holds the status code, a three-digit number that says how the request went. The groups are simple:

• 2xx means success. 200 means the page was delivered.
• 3xx means redirect. The page lives somewhere else.
• 4xx means the request was a problem. 404 is "not found," 403 is "forbidden."
• 5xx means the server had a problem. 500, 502, 503 and 504 are the usual ones.

Look up any code in the HTTP status codes reference. To see the status for many pages in a row, use the HTTP Status Checker. When you see a 5xx on your own site, go to why is my website down.

Step 3: Read the headers that help most

Header names are not case sensitive, and each is written as name: value. You do not need to know them all. These are the ones worth learning.

Identity and delivery

• server names the web server software, such as nginx, Apache or cloudflare. If it says cloudflare, a CDN sits in front of your site.
• via or x-served-by can reveal more proxies, such as a caching layer.
• cf-ray is added by Cloudflare. Seeing it confirms the request passed through their network.
• x-powered-by sometimes shows the technology, for example PHP. Hiding it is a small security hygiene step, since it tells attackers what you run.

To check whether a CDN is in use without reading headers by hand, try the CDN Detector or the Website Hosting Checker. The related guide how to find who hosts a website explains how to interpret the results.

Content

• content-type says what kind of file this is, for example text/html; charset=UTF-8. A wrong value can make a page download as a file or show garbled text.
• content-encoding shows compression, such as gzip or br (Brotli). If a text page has none, it is probably being sent larger than needed.
• content-length is the size in bytes, when the server states it.

Caching

Caching decides how long a copy of the page or file can be reused.

• cache-control is the main one. max-age=3600 means reuse for one hour. no-store means never save a copy. no-cache means check with the server before reusing. For your account or checkout pages, you usually want no caching; for images and styles, long caching is good.
• age tells you how many seconds a cached copy has been held by a cache.
• cf-cache-status (Cloudflare) shows values like HIT (served from cache), MISS (fetched from your server) or DYNAMIC (not cacheable). Other CDNs use similar headers, with names that vary by provider.
• etag and last-modified let browsers ask "has this changed?" and skip the download if not.

A page that shows no-store on your home page when you expected caching can explain a slow site. The reduce time to first byte guide shows how caching affects speed.

Redirects

When the status is 301 or 302, look for the location header. It holds the address you are being sent to.

HTTP/2 301
location: https://www.example.com/

Use the Redirect Checker to follow the whole chain. A good setup has at most one hop from http:// to the final https:// address. Long chains slow your site and can cause "too many redirects" errors. See HTTP redirects 301 vs 302.

Security headers

These tell browsers to turn on built-in protections.

• strict-transport-security (HSTS) tells browsers to use HTTPS only. Learn more in the HSTS guide and test it with the HSTS Checker.
• content-security-policy limits where scripts and other content may load from. It is powerful but easy to misconfigure; see Content Security Policy guide.
• x-content-type-options: nosniff stops browsers guessing file types.
• x-frame-options or the CSP frame-ancestors setting controls whether other sites can embed your pages in a frame.
• referrer-policy controls how much of the address is shared when a visitor clicks a link out.
• set-cookie may include Secure, HttpOnly and SameSite flags. See cookie flags explained.

Run the Security Headers Checker for a grade and a list of what is missing, and read the HTTP security headers guide before changing anything.

Step 4: Ask three questions of any header list

Faced with a long list, do not read every line. Ask:

1. What is the status? If it is not 200 or an expected redirect, that is your first lead.
2. Who answered? Check server, via and CDN headers. If you expected your host but see a CDN, you now know the failure may be in either place.
3. What is missing? Is there compression? Is HSTS present? Is caching set on static files?

Common patterns you will meet

• A 200 status with cache-control: no-store, but the page is not personal. You may be losing speed. Ask your developer why caching is off.
• A 301 that points to the same address. This is a redirect loop. Check your site's HTTPS and www settings.
• Two different server values depending on location. Different servers or CDN nodes may be answering.
• A 403 to your monitor but 200 in a browser. A firewall or bot rule is blocking automated requests.
• No content-encoding on HTML. Compression is off.

When to call your host or developer

Reading headers shows you what is happening; changing them requires access to your server or hosting settings. Contact your host or developer when:

• You want to add or change security headers and are not sure how your server or CMS sets them.
• Headers show a 5xx status that persists.
• You see a redirect loop or a long redirect chain.
• Caching is misconfigured and your site is slow or showing stale pages.
• You find a header that exposes internal details, such as version numbers or internal hostnames.

When you contact them, send the output from the header tool or your curl -I result. It saves time on both sides.

Next steps

• HTTP Header Checker to inspect any URL
• Security Headers Checker for a graded report
• HTTP security headers guide
• Test your website from another country
• Website owner monthly health checklist

FAQ

Are HTTP headers visible to everyone?

Yes. Anyone can request your pages and see the response headers, which is why you should avoid exposing version numbers or internal details in them.

What is the difference between request and response headers?

Request headers are sent by the browser (for example, which language it prefers). Response headers come from the server. This guide covers response headers, which are the ones you control.

Why do headers differ between the tool and my browser?

Your browser may send cookies or use cached data, while a tool makes a clean request from a different location. The tool is closer to what a new visitor sees.

Do I need every security header?

You do not need every one on day one. Start with HTTPS and HSTS, x-content-type-options, and a sensible referrer policy, then add others after testing.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.