Also available in: Español · Português · Français · العربية
HTTP headers list
All 257 registered fields, each with the registry's own status and the one thing the registry does not record: whether a browser will let script set it.
What is the HTTP headers list?
Every HTTP request and response carries header fields — Content-Type, Cache-Control, Authorization and the rest — and which names are real is not a matter of opinion. IANA keeps the HTTP Field Name Registry, and this page is that registry: 257 fields, each with the status IANA gave it and the specification it comes from.
Most published lists of HTTP headers are organised into request headers and response headers. That is worth knowing about, because the registry has no such column. Its five fields are the name, the status, the structured type, the reference and a free-text comment — nothing about direction. Plenty of fields travel in both directions anyway, so the split you see elsewhere is an editor's judgement presented as a fact.
What the registry does record is status, and it makes a distinction that copied tables flatten. 187 fields are permanent, 23 are provisional and still unsettled, 8 are deprecated, and 39 are obsoleted — kept so old traffic can be read, not so new traffic can use them. Nearly a fifth of the registry is something you should not be sending.
How to use it
- Search by name, by reference or by comment. One box covers all three, and results are ranked rather than merely filtered — an exact name comes first even when it would sort last alphabetically, so searching for range gives you Range and not Accept-Ranges.
- Read the badge beside each name. It says whether a browser will let script set that header on a request, and the ones it refuses are marked with which rule refuses them.
- Check the status heading above the group. Fields are grouped by what IANA says about them, so a deprecated or obsoleted name is never sitting silently beside a current one.
The column that is missing, and the one that answers it
The question people actually arrive with is not whether a header is a request or a response header. It is why setting one from JavaScript silently does nothing. That answer is in a different specification: the Fetch standard defines a forbidden request-header, and a browser drops any attempt to set one so that it keeps control of what it sends.
It is not a list. It is 21 names — Cookie, Host, Origin, Referer, Connection and company — plus two prefixes: proxy- and sec-. The prefix half is the interesting half, because it is unbounded. No header whose name begins with Sec- will ever be settable by page code, including ones nobody has invented yet, and the standard says why: the namespace is reserved so that new headers can be minted safe from the APIs that let developers set headers. That is what makes a header like Sec-Fetch-Site worth anything — a page cannot forge it.
Of the 257 registered fields, 218 are ones script may set, 20 are refused by name and 19 by prefix. One name on the forbidden list is not in the registry at all: DNT. The browser refuses to let script set a header IANA has never contained.
There is a smaller rule in the other direction too. Script can never read Set-Cookie or Set-Cookie2 off a response, whatever the CORS headers say, which is why a cookie set by a cross-origin API is invisible to the code that called it.
Honest limits, and three things worth knowing
This is a snapshot. The registry gains entries, and the date it was read is printed under the list rather than left for you to guess. A table that does not say when it was taken is quietly claiming to be current forever.
The registry also spells four of its own statuses with a capital letter, and all four are Sec-Fetch- fields. An exact-match filter on permanent returns 183 rather than 187 and drops precisely the modern fetch-metadata security headers. That is a real trap for anyone reading the CSV themselves, and it is why this page normalises the spelling.
Two entries are not headers. Close and a bare asterisk are registered with the comment reserved — that is, registered so that nobody registers them. Their status is permanent, so status alone will not tell you they are unusable, and yes, an asterisk really is a registered HTTP field name.
Some names you expect are absent. X-Forwarded-For, X-Requested-With, X-Powered-By and X-XSS-Protection are used everywhere and registered nowhere; the registered relative of the first is Forwarded. Exactly two X- fields are in the registry, and one of them is X-Frame-Options — listed as permanent, not obsoleted, which contradicts the common belief that CSP frame-ancestors retired it.
One more caveat about the safelist badge. A CORS-safelisted header avoids a preflight request only for certain values: Content-Type qualifies for three media types, so application/json preflights while text/plain does not, and every safelisted value is capped at 128 bytes. Safelisting is a property of the name and the value together, so treat that badge as a hint rather than a verdict.
Why is it free?
Because it costs nothing to run. The list is part of the page, the search happens in your browser, and nothing is uploaded or logged.
The data comes from IANA's own machine-readable file rather than from another list, the script rules come from the Fetch standard, and the script that reads both is committed alongside the data it produces so the figures on this page can be reproduced.