HTTP header fields are a list of strings sent and received by both the client program and server on every HTTP request and response. These headers are usually invisible to the end-user and are only processed or logged by the server and client applications. They define how information sent/received through the connection are encoded (as in Content-Encoding), the session verification and identification of the client (as in browser cookies, IP address, user-agent) or their anonymity thereof (VPN or proxy masking, user-agent spoofing), how the server should handle data (as in Do-Not-Track), the age (the time it has resided in a shared cache) of the document being downloaded, amongst others.

In HTTP version 1.x, header fields are transmitted after the request line (in case of a request HTTP message) or the response line (in case of a response HTTP message), which is the first line of a message. Header fields are colon-separated key-value pairs in clear-text string format, terminated by a carriage return (CR) and line feed (LF) character sequence. The end of the header section is indicated by an empty field line, resulting in the transmission of two consecutive CR-LF pairs. In the past, long lines could be folded into multiple lines; continuation lines are indicated by the presence of a space (SP) or horizontal tab (HT) as the first character on the next line. This folding was deprecated in RFC 7230.^[1]

HTTP/2^[2] and HTTP/3 instead use a binary protocol, where headers are encoded in a single HEADERS and zero or more CONTINUATION frames using HPACK^[3] (HTTP/2) or QPACK (HTTP/3), which both provide efficient header compression. The request or response line from HTTP/1 has also been replaced by several pseudo-header fields, each beginning with a colon (:).

A core set of fields is standardized by the Internet Engineering Task Force (IETF) in RFC 9110 and 9111. The Field Names, Header Fields and Repository of Provisional Registrations are maintained by the IANA. Additional field names and permissible values may be defined by each application.

Header field names are case-insensitive.^[4] This is in contrast to HTTP method names (GET, POST, etc.), which are case-sensitive.^[5]

HTTP/2 makes some restrictions on specific header fields (see below).

Non-standard header fields were conventionally marked by prefixing the field name with X- but this convention was deprecated in June 2012 because of the inconveniences it caused when non-standard fields became standard.^[6] An earlier restriction on use of Downgraded- was lifted in March 2013.^[7]

A few fields can contain comments (i.e. in User-Agent, Server, Via fields), which can be ignored by software.^[8]

Many field values may contain a quality (q) key-value pair separated by equals sign, specifying a weight to use in content negotiation.^[9] For example, a browser may indicate that it accepts information in German or English, with German as preferred by setting the q value for de higher than that of en, as follows:

Accept-Language: de; q=1.0, en; q=0.5

The standard imposes no limits to the size of each header field name or value, or to the number of fields. However, most servers, clients, and proxy software impose some limits for practical and security reasons. For example, the Apache 2.3 server by default limits the size of each field to 8,190 bytes, and there can be at most 100 header fields in a single request.^[10]

• HTTP header injection
• HTTP ETag
• List of HTTP status codes