What Is an HTTP Header?

Every time a browser loads a page or an app calls an API, a quiet exchange of metadata travels alongside the actual content. That metadata lives in HTTP headers. They tell each side how to interpret the message, who is asking, what formats are acceptable, and how the response should be cached or secured.

This guide explains what an HTTP header is, how request and response headers differ, the ones you will meet most often, and the pitfalls that trip up even experienced developers.

What an HTTP Header Actually Is

An HTTP message has two parts: a body (the payload, such as HTML, JSON, or an image) and a set of headers (the metadata describing that payload and the request or response itself). A header is simply a name and a value separated by a colon, sent as plain text before the body.

A single request or response can carry many headers. Here is a trimmed example of what a browser sends when requesting a page:

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
Accept-Encoding: gzip, br
User-Agent: Mozilla/5.0
Connection: keep-alive

The first line is the request line, not a header. Everything after it, up to the blank line that separates headers from the body, is a header. Header names are case-insensitive, so Content-Type and content-type are equivalent. In HTTP/2 and HTTP/3, header names are conventionally lowercase and the wire format is binary, but the conceptual model of name-value pairs is unchanged.

Request Headers vs. Response Headers

Headers fall into two broad roles depending on direction. Request headers are sent by the client and describe the request or the client itself. Response headers are sent by the server and describe the response or the server. Some headers, such as Content-Type, are valid in both directions.

The distinction matters because some headers only make sense in one direction. Sending Set-Cookie from a client, for instance, has no defined meaning; cookies are set by the server and echoed back by the client using the Cookie header.

How Headers Travel Through a Request

When you type a URL and press enter, the browser opens a connection to the server and writes the request line followed by its headers. The server reads them, decides how to respond, and writes its own status line and response headers back, followed by the body.

The status line carries the result code, such as 200 OK or 404 Not Found, which works together with the headers to describe the outcome. If you are unsure what a code means, our HTTP Status Code Reference lists every one. Headers and status codes are separate mechanisms: the code says what happened, the headers say how to handle it.

Because headers are just text, they are easy to inspect. You can paste a raw response into the HTTP Header Inspector to parse each name-value pair and spot missing or malformed entries.

Headers You Will Meet Most Often

A handful of headers account for the majority of real-world traffic. Knowing them well pays off quickly.

Content and encoding

• Content-Type tells the recipient the media type of the body, such as application/json or text/html; charset=utf-8. Getting this wrong is one of the most common API bugs.
• Content-Length states the body size in bytes, letting the recipient know when the message ends.
• Content-Encoding indicates compression such as gzip or br, which the client advertises support for via Accept-Encoding.

Authentication and identity

• Authorization carries credentials, often a bearer token. A JSON Web Token is a frequent payload here; our explainer on JWT tokens covers how they are structured.
• User-Agent identifies the client software. You can break one down with the User Agent Parser, though never trust it for security since clients can send any value.

Caching and state

• Cache-Control dictates how long a response may be stored and by whom, using directives like max-age=3600 or no-store.
• Set-Cookie and Cookie manage session state between server and client.

Security and Cross-Origin Headers

A growing share of headers exists purely to enforce browser security policy. These are response headers the server sets, and the browser enforces them on the client side.

Cross-origin resource sharing is governed by headers beginning with Access-Control-. They decide whether a page on one origin may read a response from another. The mechanics are subtle, so it is worth reading what CORS is and assembling correct values with the CORS Headers Builder rather than guessing.

Other widely used security headers include Content-Security-Policy, which restricts where scripts and other resources may load from, Strict-Transport-Security, which forces HTTPS, and X-Content-Type-Options: nosniff, which stops browsers from second-guessing the declared content type. These do not change the body at all; they change how the browser is allowed to treat it.

Common Pitfalls With Headers

Headers look simple, but several recurring mistakes cause real outages and security gaps.

• Wrong or missing Content-Type. Sending JSON without Content-Type: application/json leads many servers and clients to misparse the body. This is the single most frequent header bug in API work.
• Trusting client-supplied headers for security. Values like User-Agent, Referer, and even X-Forwarded-For can be set to anything by the caller. Never make an access decision based on them alone.
• Forgetting that headers are case-insensitive but order-sensitive in subtle ways. You may read content-type regardless of case, but duplicate headers and their handling vary, so avoid sending the same header twice with conflicting values.
• Putting secrets in headers that get logged. Tokens in Authorization often end up in access logs or proxies. Treat them as sensitive and avoid logging full header sets in production.
• Header size limits. Servers cap total header size, commonly around 8 KB. Oversized cookies or bloated tokens can trigger a 431 Request Header Fields Too Large error.

Once you internalize that headers are just structured metadata riding alongside the body, most of HTTP becomes far easier to reason about. They control content negotiation, caching, authentication, and security, and being deliberate about the ones you send and accept is a hallmark of robust web software.

Frequently Asked Questions