# HTTP Header Check

> Read every response header back in plain language.

Response header checker sends one real GET request to a URL and explains every response header that comes back — what it does, what the value you have actually means, and what to change — grouped into security, CORS, caching and payload.

Also: http header checker, response header checker, check security headers, cors header checker, cache control checker, view http headers online, security headers scan.

## What it does

Response headers are where a surprising amount of production behaviour is decided, and almost none of it is visible from the code. A permissive CORS rule, a cache directive that stores a per-user response in a shared CDN, or a missing HSTS header are all one line of config and all invisible until something goes wrong. This reads the headers a URL actually returns and grades them, so the gap between what you think you deployed and what the edge is really sending shows up in one request.

## When to use it

- You want to know whether a URL sets the security headers a review or a pen test will ask about.
- A cross-origin call fails in the browser and you need to see what the CORS headers really say.
- You are debugging stale data and want to see the exact caching directives in play.
- You changed edge config and want to confirm what the CDN is now sending.
- You want to know whether responses are compressed, and with what.

## What you give it

| Input | Meaning |
| --- | --- |
| URL | Any public http or https URL, path and query included. HTTPS is assumed when you leave the scheme off. |

## What you get back

| Output | Meaning |
| --- | --- |
| Headers worth fixing | A count of the headers that are missing or set to a permissive value, and a status for the response overall. |
| A grade per area | Security, CORS, caching and payload each graded A to D by how many issues they carry. |
| Per-header explanation | For every header: what it does in general, what your specific value means on this response, and the concrete change to make. |
| Every header received | Headers outside the checked set are still listed, so nothing the server sent is hidden. |

## How it works

- Postman sends one GET request to the URL from a server, and reads the response headers.
- The response body is discarded — only the headers are used.
- Each catalogued header is judged on its actual value, not merely on whether it is present, so a one-minute HSTS max-age is not scored the same as a one-year one.
- Some rules read each other: a wildcard CORS origin is judged differently when credentials are also allowed, and a missing Vary: Origin only matters when CORS is in play.
- Each area is graded A to D, one step worse per issue found.

## Key terms

- **HSTS** — Strict-Transport-Security. Tells a browser to reach this host only over HTTPS for a set period, so a plaintext first request cannot be intercepted. Its value is the whole point — a short max-age lapses almost immediately.
- **CORS** — the rules deciding whether JavaScript on another origin may read a response. A wildcard origin is safe for genuinely public data and a leak for anything that varies by cookie or key.
- **Vary** — tells shared caches which request headers change the response, so they store separate copies. Omitting Origin while CORS headers depend on it lets a cache serve one site the response computed for another.
- **Content sniffing** — a browser guessing a response type when the declared Content-Type looks wrong. `X-Content-Type-Options: nosniff` turns the guessing off, which stops a response being re-interpreted as script.

## Questions

### Does it send a HEAD request or a GET?

A GET, with the body read and thrown away. HEAD is unreliable for this: many servers answer 405, and others omit Content-Length and Content-Encoding on HEAD, which would misreport the payload headers.

### Why does it not flag every missing header as a problem?

Because absence is not always a fault. A plain GET has no reason to carry preflight CORS headers, and a response that no cross-origin site should read is correct to send no Access-Control-Allow-Origin at all. Only headers whose absence is itself the problem are marked missing.

### Are the grades a security score?

No. They count issues in each area, one letter worse per issue, and stop at D. They are a way to see where to look first, not an assessment of how secure a service is.

### Can it check a URL behind authentication?

Not here — the request is sent with no credentials. Sending a request with headers and auth you control is what the REST API Client is for.

### Can it check a localhost or internal URL?

No. The request is sent by Postman rather than by your browser, so it can only reach publicly resolvable hosts.


## Privacy

The URL is sent to Postman so the request can be made from a server, which is the only way to read response headers a browser would hide. The response body is discarded and never shown, no account is needed, and nothing about the response is stored.

## Links

- [Use the tool](https://www.postman.com/tools/http-header-check) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [Guide to sending requests](https://learning.postman.com/docs/sending-requests/requests/) — Postman documentation.