files/en-us/web/http/reference/headers/index.md
HTTP headers let the client and the server pass additional information with a message in a request or response.
In HTTP/1.X, a header is a case-insensitive name followed by a colon, then optional whitespace which will be ignored, and finally by its value (for example: Allow: POST).
In HTTP/2 and above, headers are displayed in lowercase when viewed in developer tools (accept: */*), and prefixed with a colon for a special group of pseudo-headers (:status: 200).
You can find more information on the syntax in each protocol version in the HTTP messages page.
Custom proprietary headers have historically been used with an X- prefix, but this convention was deprecated in 2012 because of the inconveniences it caused when nonstandard fields became standard in RFC 6648; others are listed in the IANA HTTP Field Name Registry, whose original content was defined in RFC 4229.
The IANA registry lists headers, including information about their status.
Headers can be grouped according to their contexts:
Headers can also be grouped according to how {{Glossary("Proxy_server", "proxies")}} handle them:
For more details, refer to the Content negotiation article.
TRACE, indicates the maximum number of hops the request can do before being reflected to the sender.For more information, refer to the CORS documentation.
Content- analogue of {{HTTPHeader("Want-Repr-Digest")}}.Repr- analogue of {{HTTPHeader("Want-Content-Digest")}}.Integrity-Policy header).Preferences can be sent by clients in requests to indicate optional behaviors for requests and responses. The server response may indicate if a preference is applied, in cases where it would otherwise be ambiguous for the client. Browsers have no native handling for sending preferences via these headers; they are used in custom, implementation-specific clients.
return=minimal) or asynchronous processing (respond-async). The server processes the request normally if the header is unsupported.Prefer header were applied by the server. It is a response-only header providing transparency about preference handling.HTTP range requests allow the client to request a portion of a resource from the server. Range requests are useful for applications like media players that support random access, data tools that know they need only part of a large file, and download managers that let the user pause and resume a download.
meta element with http-equiv="refresh".POST request to the specified URI.X-Permitted-Cross-Domain-Policies header overrides such policy files so that clients still block unwanted requests.{{Glossary("Fetch metadata request header", "Fetch metadata request headers")}} provide information about the context from which the request originated. A server can use them to make decisions about whether a request should be allowed, based on where the request came from and how the resource will be used.
cross-site, same-origin, same-site, and none.cors, navigate, no-cors, same-origin, and websocket.?0 for false and ?1 for true.audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker, and xslt.The following request headers are not strictly "fetch metadata request headers", but similarly provide information about the context of how a resource will be used. A server might use them to modify its caching behavior, or the information that is returned:
prefetch, which indicates that the resource is being fetched preemptively for a possible future navigation.fetch() operation.These headers enable an enhanced workflow for the Storage Access API.
none, inactive, or active.
The server may respond with Activate-Storage-Access to request that the browser activate an inactive permission and retry the request, or to load a resource with access to its third-party cookies if the status is active.Sec-Fetch-Storage-Access to indicate that the browser can activate an existing permission for secure access and retry the request with cookies, or load a resource with cookie access if it already has an activated permission.Headers used by the WebSockets API in the WebSocket handshake:
WebSocket.The Attribution Reporting API enables developers to measure conversions — for example when a user clicks an ad embedded on one site and then proceeds to purchase the item over on the vendor's site — and then access reports on those conversions. It does this without relying on third-party tracking cookies, instead relying on various headers to register sources and triggers that are matched to indicate a conversion.
Attribution-Reporting-Eligible header, this is used to register an attribution source.Attribution-Reporting-Eligible header, this is used to register an attribution trigger.HTTP Client hints are a set of request headers that provide useful information about the client such as device type and network conditions, and allow servers to optimize what is served for those conditions.
Servers proactively requests the client hint headers they are interested in from the client using {{HTTPHeader("Accept-CH")}}. The client may then choose to include the requested headers in subsequent requests.
Accept-CH header field or an equivalent HTML <meta> element with http-equiv attribute.Critical-CH along with {{HTTPHeader("Accept-CH")}} to specify that accepted client hints are also critical client hints.The different categories of client hints are listed below.
The UA client hints are request headers that provide information about the user agent, the platform/architecture it is running on, and user preferences set on the user agent or platform:
[!NOTE] User-agent client hints are not available inside fenced frames because they rely on permissions policy delegation, which could be used to leak data.
Network client hints allow a server to choose what information is sent based on the user choice and network bandwidth and latency.
on that indicates the user agent's preference for reduced data usage.Compression Dictionary Transport is a way of using a shared compression dictionary to reduce the transport size of HTTP responses rather than using the standard static dictionary in {{glossary("Brotli compression")}} or {{glossary("Zstandard compression")}}.
id for the dictionary in the Use-As-Dictionary header.
Requests for resources that can use the dictionary have an Available-Dictionary header and the server-provided dictionary id in the Dictionary-ID header.The Topics API provides a mechanism for developers to implement use cases such as interest-based advertising (IBA). See the Topics API documentation for more information.
Accept-Signature header field to indicate intention to take advantage of any available signatures and to indicate what kinds of signatures it supports.POST and PATCH requests, allowing them to be made idempotent.Signature header field conveys a list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature.Signed-Headers header field identifies an ordered list of response header fields to include in a signature.Supports-Loading-Mode value of credentialed-prerender.X-Robots-Tag HTTP header is used to indicate how a web page is to be indexed within public search engine results. The header is equivalent to <meta name="robots"> elements.Cache-Control header is not yet present.