HTTP Headers

Lists the media types (MIME) the client will accept as a response, in preference order — the server uses this to pick the body format (e.g. JSON vs. XML) when more than one is available.

Lists the compression encodings the client knows how to decompress (e.g. gzip, br, deflate) — the server compresses the body with one of them and reports which via Content-Encoding.

Lists the client's preferred languages, in order — used by servers that serve translated content to automatically pick the response language.

Sends back to the server every cookie already saved for that domain, one after another — the request side of the pair with Set-Cookie, added automatically by the browser.

Asks the server for confirmation before the client sends the request body — the most common use is Expect: 100-continue, to avoid sending a large body the server would reject anyway.

Reports the contact email of whoever is making the request — used almost exclusively by crawlers/bots, so the site's administrator knows who to report an issue to.

Says which domain the request is meant for — required since HTTP/1.1, it's what lets a single server/IP host several different domains (virtual hosting).

Limits how many intermediate proxies/hops can still forward the request — used mainly with the TRACE and OPTIONS methods, to debug a chain of proxies.

Signals a request's relative priority (urgency, and whether it should be processed incrementally) — gives the server a hint about which resources to deliver first, especially useful over HTTP/2 and HTTP/3.

Reports the URL of the page that originated the request — the name keeps the original specification's historical misspelling (it should be "Referrer"), preserved for compatibility. Referrer-Policy controls what this header reveals.

Identifies the client software that made the request — browser and version, operating system, or the name of a bot/tool. Used both for statistics and to serve adapted content.

Reports which media types the server accepts in a PATCH body for that resource — usually sent in an OPTIONS response, as part of negotiating how to partially edit the resource.

Same idea as Accept-Patch, but for the POST method — reports which media types the server accepts in a POST request body for that resource.

Lists the HTTP methods supported by that resource (e.g. GET, POST, HEAD) — required in a 405 Method Not Allowed response, also common in responses to OPTIONS.

Describes a relationship between the current response and another resource (e.g. rel="next" for pagination, rel="preload" to get a asset loading earlier) — the header version of what the HTML <link> tag does.

Points to the URL the client should go to — used in redirects (3xx) to give the new address, and in resource creation (201 Created) to point at the newly created resource.

Instructs the browser to reload the current page, or navigate to another URL, after a number of seconds — the header equivalent of <meta http-equiv="refresh">.

Says how long the client should wait before trying again — used with 429 Too Many Requests and 503 Service Unavailable, as a number of seconds or as a date.

Identifies the server software that generated the response — advertising the exact version is often discouraged for security, since it makes it easier to target a known vulnerability in that version.

Carries server-side performance metrics (e.g. database query time) that become visible in the browser's developer tools — useful for diagnosing where response time is being spent.

Creates or updates a cookie on the client — a response can have several Set-Cookie headers, one per cookie. The attributes (Secure, HttpOnly, SameSite, Max-Age...) control where and for how long the cookie gets sent back.

Instructs search engines on how to index that page (e.g. noindex, nofollow) — the header version of what the <meta name="robots"> tag does in HTML, useful for files that aren't HTML (PDF, image).

Announces that the server supports partial byte-range requests for that resource (e.g. Accept-Ranges: bytes) — what allows resuming an interrupted download or jumping straight to a point in a video.

Says how the body should be handled by the client — displayed inline (default) or downloaded as an attachment, with a suggested filename.

Says which compression encoding was applied to the body (e.g. gzip, br) — the client needs to decompress with the indicated algorithm before interpreting the content.

Says the language of the body's content (e.g. en-US) — information for whoever consumes the response, different from Accept-Language, which is the client's preference.

Says the exact size of the body in bytes — lets the client know when the message has ended and show download progress; absent when the body uses Transfer-Encoding: chunked.

Points to an alternate URL where the same response content can also be accessed directly — common when the response results from content negotiation (e.g. it came from /doc but also exists at /doc.en-us).

Indicates which byte range of the full resource is being delivered in that partial response (206 Partial Content), and the resource's total size — the return of what Range asked for.

Says the media type (MIME) of the body (e.g. application/json, text/html; charset=utf-8) — the most fundamental header for the client to know how to interpret the bytes received.

Makes a partial-range request (Range) conditional — only returns the requested chunk if the resource hasn't changed since a given ETag/date; otherwise returns the entire resource, avoiding a file assembled from pieces of different versions.

Requests only a byte range of the resource, not the whole thing (e.g. bytes=200-999) — the basis for resumable downloads and seekable video streaming.

Says how many seconds ago the response was generated by the origin server and is being served from an intermediate cache — helps the client know how "fresh" the cached copy really is.

Controls whether, where, and for how long a response can be stored in cache and reused — directives like max-age, no-store, private/public, and must-revalidate. It's the recommended caching mechanism today, taking priority over Expires when both appear.

Instructs the browser to delete stored data for that origin — cookies, cache, local storage — typically sent in a logout response, to make sure nothing from the previous session survives on the device.

An opaque identifier (a kind of "hash") for a resource's current version — the client sends this value back in If-None-Match/If-Match on a future request, and the server responds 304 Not Modified if nothing changed, without resending the body.

An absolute date after which the cached response is considered stale — an older caching mechanism than Cache-Control, and since it's a date (not a relative value), it's sensitive to clock drift between client and server.

Makes the request conditional on a specific ETag — only executes if the resource on the server still has that ETag, preventing an unnoticed overwrite of a newer version (protection against "lost update").

Makes the request conditional on a date — the server only resends the body if the resource was modified after the given date; otherwise it responds 304 Not Modified. The date-based version of what If-None-Match does with an ETag.

Makes the request conditional on the given ETag — the server only resends the body if the resource's current ETag differs from the one sent; it's the most precise cache-revalidation mechanism, preferred over If-Modified-Since when both are available.

Makes the request conditional on a date — only executes if the resource hasn't been modified since then; used mostly in edits (PUT/PATCH) to avoid overwriting a more recent change.

Says the date the resource was last modified — used together with If-Modified-Since/If-Unmodified-Since for date-based cache revalidation, a simpler (though less precise) alternative to ETag.

A holdover from HTTP/1.0 — Pragma: no-cache was meant to prevent caching, but was only reliably honored on requests, never on responses. Cache-Control: no-cache is the direct replacement and works in both directions.

Lists which other request headers (e.g. Accept-Encoding, Accept-Language) influence which version of the response gets served — essential so a cache doesn't mistakenly return the version in another language, or the uncompressed one, to someone who asked for something different.

Used to carry extra warnings about the cache's state (e.g. a potentially stale response) alongside a response — deprecated by the current caching specification itself, with no real adoption among browsers.

Defines which origins the page can load scripts, styles, images, and other resources from — the most effective defense against XSS, by restricting what an injected script could even try to load. Evaluated live by the Security Headers Analyzer.

Same syntax as Content-Security-Policy, but only reports violations (via a report endpoint) instead of blocking them — used to test a new policy in production without risking breaking the page.

Requires every resource embedded in the page (images, iframes, scripts from another origin) to explicitly opt in to being embedded — a prerequisite for enabling cross-origin isolation, needed for example for SharedArrayBuffer.

Isolates the page's window/tab from other windows of different origins that opened it or that it opened — prevents a malicious tab from keeping a script reference to the page and reading its state.

Controls whether other origins can load that specific resource (image, script, font) via HTML tags — a simpler, more granular protection than CORS, from the side of whoever serves the resource.

Required a site's TLS certificate to be publicly logged in a Certificate Transparency log, with failure reporting — removed by major browsers because that requirement is now enforced directly at certificate issuance, without depending on a header.

Controls which browser features and APIs the page (and iframes within it) can use — camera, microphone, geolocation, and dozens more. Successor to the old Feature-Policy. Evaluated live by the Security Headers Analyzer.

Controls how much information from the origin URL (Referer) gets sent when navigating to another site or loading a resource — from "nothing" to "full URL", balancing privacy against how useful that information is to the receiver. Evaluated live by the Security Headers Analyzer.

Added automatically by the browser (can't be overridden via JavaScript) — says what purpose the resource was requested for: document, image, script, style, and others. Servers use it to block requests outside the expected context.

Added automatically by the browser — says the mode of the fetch request: navigate, cors, no-cors, same-origin. Together with Sec-Fetch-Site, it helps the server tell legitimate navigation apart from a cross-site attack.

Added automatically by the browser — says the relationship between the requesting origin and the target origin: same-origin, same-site, cross-site, or none (typed directly into the address bar). The basis of a modern CSRF defense that doesn't rely on a token.

Instructs the browser to only connect to that domain over HTTPS, for the given duration — even if the user types http:// or clicks an old link. Protects against downgrade attacks that try to force an insecure connection. Evaluated live by the Security Headers Analyzer.

Signals that the client prefers to receive the HTTPS version of any resource referenced on the page, even if the original link points to HTTP — the browser automatically rewrites those requests.

With the only valid value nosniff, prevents the browser from trying to guess ("sniff") a file's type differently from what Content-Type declared — blocks a classic XSS vector where a file disguised as an image was interpreted as a script. Evaluated live by the Security Headers Analyzer.

Turns the browser's automatic DNS prefetching for the page's links on or off, before the user even clicks — turning it off reduces a small leak surface of which domains the user is about to visit.

Controls whether the page can be displayed inside an <iframe> from another site — DENY blocks it always, SAMEORIGIN only allows it from the same domain. Protects against clickjacking; the frame-ancestors directive in Content-Security-Policy is the more modern, flexible replacement. Evaluated live by the Security Headers Analyzer.

Controls whether Flash and Adobe Reader readers (essentially extinct today) can load a cross-domain policy file from that site — relevant almost only to very old sites still hosting that kind of content.

Discloses the technology behind the server (e.g. Express, PHP/8.2) — the common security recommendation is to remove this header, not configure it, so as not to make it easier for an attacker to pick exploits targeted at that technology/version.

Used to switch on the reflected-XSS filter built into older browsers — removed by modern browsers because the filter itself created attack vectors; Content-Security-Policy solves the same problem more safely.

Says whether the response can be read when the request was made with credentials (cookies, an Authorization header) — without this header set to true, the browser discards the response of a cross-origin request made with credentials: "include".

Lists which request headers, beyond the ones allowed by default, the server accepts on a cross-origin request — the answer to the question asked by the preflight's Access-Control-Request-Headers.

Lists which HTTP methods the server accepts on a cross-origin request for that resource — the answer to the question asked by the preflight's Access-Control-Request-Method.

Says which origins are allowed to read the response of a cross-origin request — a specific domain, or * for any origin (incompatible with credentials). The most fundamental CORS header; without it, the browser blocks reading the response.

Lists which response headers, beyond a small safe default set, the client's JavaScript can actually read on a cross-origin request.

Says for how many seconds the browser can reuse the result of a preflight (the verification OPTIONS request) without repeating it — reduces the extra latency CORS adds to subsequent requests.

Sent by the browser in the preflight (OPTIONS) request — lists the headers the real request intends to send, asking the server whether it accepts them.

Sent by the browser in the preflight (OPTIONS) request — says which method the real request will use, asking the server whether it accepts it.

Says which origin (scheme + domain + port) the request came from — sent automatically by the browser on cross-origin requests, and what the server compares against its CORS policy to decide the response's Access-Control-Allow-Origin.

Says which origins are allowed to read detailed timing metrics (via the Resource Timing API) for a resource loaded cross-origin — without it, scripts from another origin only see zeroed-out timestamps for privacy.

Carries the client's credentials for authentication — a scheme (Basic, Bearer, Digest...) followed by the value (e.g. Bearer eyJhbGci...). The standard header for sending an API token or a JWT.

Sent by a proxy (not the final server) alongside 407 Proxy Authentication Required, indicating which authentication scheme the proxy requires before forwarding the request.

Carries the client's credentials to authenticate to an intermediate proxy — same idea as Authorization, but addressed to the proxy, not the final server.

Sent by the server alongside 401 Unauthorized, indicating which authentication scheme it requires — the client responds on a following request with the matching Authorization header.

Announces that the same resource is also available over an alternate protocol/host/port (e.g. an HTTP/3 version over QUIC) — lets the browser migrate to the alternative on future connections, at no cost to the current request.

Sent by the client to report which alternative service (previously announced via Alt-Svc) is actually being used for that request — helps the server monitor adoption of an alternate route.

Controls options specific to that TCP connection, most commonly keep-alive (keeps the connection open for more requests) or close (closes after this response) — over HTTP/2 and HTTP/3 this header stops making sense, since the connection is always multiplexed.

Says the date and time the message originated, in the GMT timezone — used, among other things, as the time reference for relative cache calculations (Age, Expires).

Standardizes the information proxies and load balancers add about the original request — client IP, original protocol and host — into a single structured header, formally replacing the non-standard X-Forwarded-* trio.

Adjusts parameters of a persistent connection (e.g. how long to stay idle before closing) — never formally part of the HTTP/1.1 standard, but still sent by many servers as a holdover from HTTP/1.0.

Sent by the server to confirm the WebSocket upgrade handshake — a value computed from the client's Sec-WebSocket-Key, proving the response came from a server that actually understands the WebSocket protocol.

Sent by the client in the WebSocket upgrade handshake — a random value the server must transform in a specific way and return in Sec-WebSocket-Accept, to confirm it accepted the protocol.

Negotiates which application subprotocol will run over the WebSocket connection (e.g. "chat", "graphql-ws") — the client lists the ones it supports, the server responds with the one it picked.

Says which version of the WebSocket protocol the client is using — today essentially always 13, the final version standardized by RFC 6455.

Lists the transfer codings (not to be confused with Content-Encoding) the client accepts besides chunked, and whether it accepts trailers — used almost exclusively to negotiate end-to-end vs. hop-by-hop compression.

Announces, at the start of the message, which headers will still arrive after the body (in the trailer of a chunked message) — useful for headers whose value is only known after the whole body has been processed, like a checksum.

Says how the body was encoded for transfer between the two ends of the connection (typically chunked, in variable-sized pieces) — different from Content-Encoding, which is about the content itself, not how it traveled.

Asks to switch the current connection's protocol to another one (e.g. to websocket, or from HTTP/1.1 to HTTP/2) — the basis of the handshake that promotes a plain HTTP connection to WebSocket.

Records every proxy or gateway the message passed through, in order — used to trace a request/response's path through intermediaries, and to avoid forwarding loops.

Records the chain of client/proxy IPs the request passed through before reaching the final server — essential for a server behind a proxy/load balancer to know the real IP of whoever made the request, since the direct TCP connection comes from the proxy.

Records the request's original Host, before passing through a proxy that might rewrite it — used by the application to know which domain the user actually visited.

Records whether the original request reached the proxy over http or https — essential when TLS terminates at the proxy/load balancer and the application behind it only ever sees plain HTTP traffic, but still needs to know the user is on a secure connection.