# How I read HTTP headers when an API or website behaves strangely

A beginner-friendly guide to HTTP headers, content type, caching, cookies, redirects, security headers, and using an HTTP Header Parser.

- Date: 2026-09-27
- URL: https://ilham.dev/posts/how-to-read-http-headers/
- Markdown: https://ilham.dev/posts/how-to-read-http-headers/index.md
- Tags: http, headers, api, tools
- Reading time: 3 min


HTTP headers are small pieces of metadata sent with a request or response. They can
explain things that are not visible in the page body.

When a website or API behaves strangely, I often look at the headers first.

The [HTTP Header Parser](/tools/http-header-parser/) turns a raw header block into a
clean table so it is easier to inspect.

## The simple idea

An HTTP response has a status line, headers, and a body.

Example:

```http
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Set-Cookie: session=abc; HttpOnly; Secure
```

Plain meaning:

- status is `200 OK`;
- body is JSON;
- response should not be stored in cache;
- server is setting a secure cookie.

## Step 1: copy the raw headers

You can copy headers from browser DevTools, an API client, or command-line output.

Example with curl:

```sh
curl -I https://example.com
```

Then paste the header block into [HTTP Header Parser](/tools/http-header-parser/).

## Step 2: check Content-Type

`Content-Type` tells the client what kind of body it received.

Examples:

```http
Content-Type: text/html
Content-Type: application/json
Content-Type: image/png
```

If an API returns JSON but the content type says `text/html`, some clients may handle
it incorrectly.

## Step 3: check caching headers

Caching bugs can make old data appear even after the server changed.

Common headers:

```http
Cache-Control: no-store
Cache-Control: max-age=3600
ETag: "abc123"
```

`max-age=3600` means the response can be cached for one hour. `no-store` means do
not store it.

If a page refuses to update, cache headers are worth checking.

## Step 4: check redirects

Redirect responses often use status codes like:

```text
301
302
307
308
```

and a `Location` header:

```http
Location: https://example.com/new-page
```

If a login flow or API call goes to the wrong place, inspect the redirect chain.

## Step 5: check cookies

Cookies are set with `Set-Cookie`:

```http
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax
```

Useful attributes:

- `HttpOnly`: JavaScript cannot read it;
- `Secure`: sent only over HTTPS;
- `SameSite`: controls cross-site cookie behaviour;
- `Path` and `Domain`: control where the cookie applies.

Cookie bugs often come from missing `Secure`, wrong domain, or SameSite behaviour.

## Step 6: check security headers

Security headers can reduce browser risks.

Examples:

```http
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self'
```

You do not need every header on every site, but reading them helps understand how the
browser is being instructed.

## Step 7: watch repeated headers

Some headers can appear more than once. `Set-Cookie` is the common example.

A parser is useful because it can show repeated headers clearly instead of hiding one
behind another.

## My header checklist

When debugging headers, I check:

1. What is the status code?
2. Is `Content-Type` correct?
3. Are caching headers expected?
4. Is there a redirect `Location`?
5. Are cookies set with the right attributes?
6. Are security headers present where needed?
7. Are repeated headers handled correctly?

Headers are not the content, but they often explain why the content behaves the way
it does.