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

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 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/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:

curl -I https://example.com

Then paste the header block into HTTP Header Parser.

Step 2: check Content-Type

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

Examples:

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:

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:

301
302
307
308

and a Location header:

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:

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:

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.