HTTP headers
The HTTP headers you'll actually read or set — request, response, CORS and security — each translated into one plain-English line.
Last updated
Request headers
| Header | What it does |
|---|---|
| Authorization | Carries the credential proving who's asking — a bearer token, API key, or Basic auth pair. |
| Content-Type | Tells the server how the request body is encoded, e.g. application/json. |
| Accept | Tells the server which response formats the client can handle. |
| User-Agent | Identifies the client software making the request — browser, bot, or app. |
| Cookie | Sends back the cookies the server previously set for this domain. |
| If-None-Match | Sends a cached ETag so the server can reply 304 if nothing changed. |
| Origin | The scheme+host+port the request came from — what CORS checks are based on. |
| Referer | The page the request was linked or triggered from (yes, misspelled in the spec). |
Response headers
| Header | What it does |
|---|---|
| Content-Type | Tells the client how to interpret the response body, e.g. text/html or image/png. |
| Cache-Control | Sets how long, and under what conditions, this response may be cached. |
| ETag | A fingerprint of the response body, used to check for changes without resending it. |
| Location | Where to go instead — used with redirects and after creating a resource. |
| Set-Cookie | Stores a cookie in the client for future requests to this domain. |
| Content-Disposition | Suggests the browser download the response as a file, with a given name. |
| Retry-After | Tells the client how long to wait before trying again, usually with a 429 or 503. |
CORS
| Header | What it does |
|---|---|
| Access-Control-Allow-Origin | Lists which origins may read this response from a cross-origin request. |
| Access-Control-Allow-Methods | Lists which HTTP methods a cross-origin request is allowed to use. |
| Access-Control-Allow-Headers | Lists which request headers a cross-origin request is allowed to send. |
| Access-Control-Allow-Credentials | Permits cookies and auth headers to be included in a cross-origin request. |
| The preflight | Before certain cross-origin requests, the browser sends an OPTIONS request to check permission first. |
Security
| Header | What it does |
|---|---|
| Strict-Transport-Security | Forces the browser to use HTTPS for this domain, even if a link says http://. |
| Content-Security-Policy | Restricts which sources scripts, styles and other resources may load from. |
| X-Content-Type-Options | Set to nosniff, stops the browser guessing a file's type from its content. |
| X-Frame-Options | Controls whether this page may be embedded in an iframe, preventing clickjacking. |
| Referrer-Policy | Controls how much of the current URL is sent as Referer on outgoing requests. |
Worth remembering
- →A CORS failure is a browser-side block, not a server error — the request usually succeeded, the browser just won't hand the response to your script.
- →Access-Control-Allow-Origin can't be "*" alongside Access-Control-Allow-Credentials — credentialed requests require an exact origin to be named.
Questions
Which headers are actually worth setting?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and a Referrer-Policy cover most of the value. The rest are situational, and several once-recommended ones are now obsolete.
Why does my CORS header not work?
Access-Control-Allow-Origin is a response header — setting it on the request does nothing. The other common cause is an unhandled OPTIONS preflight, which means the real request never happens.
What is the difference between no-cache and no-store?
no-cache allows storage but requires revalidation before use; no-store forbids storing the response at all. Sensitive pages want no-store, and most pages want neither — a short max-age is usually better.
Are X- prefixed headers still standard?
The convention was formally deprecated, and several X- headers remain in wide use — X-Content-Type-Options is still the correct name. New custom headers should not use the prefix.
How do I see what a server actually sends?
curl -I shows the response headers with a HEAD request, and -IL follows redirects so you see every hop. Add -v when you also need to see what was sent.