Headers Are Metadata, Not Content
An HTTP message has two parts: a body and a set of headers. The body is the payload — the HTML of a page, the bytes of an image, the JSON an API returns. The headers are everything about that payload. Each header is a single line written as a name, a colon, and a value:
Content-Type: text/html; charset=utf-8That one line tells the browser the body is HTML encoded as UTF-8, which is enough for it to know whether to render the bytes as a page, display them as an image, or offer them as a download. A typical request or response carries a dozen or more such lines. They are sent immediately after the request line or status line and before the body, separated from it by a blank line. If you want the bigger picture of where headers sit in the exchange, see how HTTP works and the status code that opens every response.
Header names are case-insensitive (Content-Type and content-type mean the same thing), and in HTTP/2 and HTTP/3 they are even compressed and lower-cased on the wire. But the idea is unchanged from the earliest web: a list of name–value pairs that lets two machines that have never met agree on how to talk.
Request Headers: What the Browser Says
When your browser asks for something, it attaches headers describing itself and its preferences. The server reads them to decide what — and how — to send back. The most common ones:
| Header | What it tells the server |
|---|---|
Host | Which website is wanted. One server (one IP) can host many sites, so this header picks the right one. It is the only header required in HTTP/1.1. |
User-Agent | The browser and operating system making the request. See what a user agent is. |
Accept | The content formats the client can handle, e.g. text/html or application/json. |
Accept-Encoding | Which compression schemes the client understands — the basis of gzip and Brotli compression. |
Accept-Language | Preferred languages, used to serve a localised page. |
Cookie | Returns the cookies the server set earlier — how it recognises a logged-in session. |
Referer | The page you came from (yes, the spelling is a famous typo baked into the standard). |
Authorization | Credentials or a token proving who you are to a protected resource. |
Notice that the client chooses these values. That makes most request headers useful hints but unreliable proof — a script can claim any User-Agent it likes, which is why servers treat such headers as preferences rather than identity.
Response Headers: What the Server Answers
The server replies with its own headers describing the response. These instruct the browser on how to interpret, store, and secure what it has just received:
| Header | What it controls |
|---|---|
Content-Type | The format of the body — see MIME types. Getting this wrong is why a page sometimes shows as raw code. |
Content-Length | The size of the body in bytes, so the browser knows when it has received all of it. |
Content-Encoding | Which compression was applied, so the browser can decompress before reading. |
Cache-Control | How long, and whether, the response may be reused without re-fetching — the heart of web caching. |
Set-Cookie | Asks the browser to store a cookie and send it back on future requests. |
Location | The new address to follow on a redirect (paired with a 3xx status code). |
Strict-Transport-Security | Forces the browser to use HTTPS for future visits — see HSTS. |
A few headers appear on both sides because caching is a negotiation. The server may send ETag (a fingerprint of the content); on the next visit the browser sends it back in an If-None-Match request header, and if nothing changed the server replies 304 Not Modified with no body at all. That round-trip — driven entirely by headers — is why a revisited page loads almost instantly.
A Real Exchange, Header by Header
Here is a trimmed request and response for a single page. The request your browser sends:
GET /guides/ HTTP/1.1
Host: speedtesthq.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Accept-Encoding: gzip, br
Cookie: session=ab12cd34And the response the server returns:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Cache-Control: max-age=3600
Strict-Transport-Security: max-age=63072000Read top to bottom, the story is complete: the browser wanted the guides page on this host, would accept HTML and could handle Brotli compression, and presented a session cookie. The server said the request succeeded (200), the body is Brotli-compressed UTF-8 HTML, it may be cached for an hour, and the site should only ever be loaded over HTTPS. Not a byte of page content yet — just two machines agreeing on the terms.
Security Headers and Custom Headers
A growing class of response headers exists purely to harden the browser against attacks. Content-Security-Policy restricts where scripts and images may load from, blunting cross-site scripting. X-Content-Type-Options: nosniff stops the browser from second-guessing a declared content type. Strict-Transport-Security locks the site to HTTPS. These cost nothing to send and are among the cheapest security wins a site can deploy.
Beyond the standard set, applications invent their own headers to carry information the protocol never anticipated — an API request ID for tracing, a Retry-After hint on a rate-limited response, a token in a custom X-Api-Key line. For years the convention was to prefix such names with X-; that practice is now discouraged in favour of plain descriptive names, but you will still meet X- headers everywhere. The flexibility is the point: headers are an open-ended channel for metadata, which is exactly why HTTP has lasted as long as it has.
Frequently Asked Questions
What is an HTTP header?
A single line of metadata — a name, a colon, and a value — that travels alongside an HTTP request or response. Headers describe the message rather than carry its content: the body's format, the client's preferences, caching rules, security policies, and more.
What is the difference between request headers and response headers?
Request headers are sent by the client and describe it and its preferences (Host, User-Agent, Accept, Cookie). Response headers are sent by the server and describe the reply (Content-Type, Cache-Control, Set-Cookie). Caching headers such as ETag appear on both sides.
Are HTTP headers encrypted?
Over HTTPS, yes — TLS encrypts the whole message including headers, so they cannot be read in transit. The exception is the destination hostname during setup (SNI), sent in the clear unless Encrypted Client Hello is used. Over plain HTTP, headers are not encrypted.
How do I view the HTTP headers for a page?
Open your browser's developer tools, switch to the Network tab, reload, and click a request to see its headers. From a terminal, curl -I prints response headers and curl -v shows the full exchange.
Can headers be made up or customised?
Yes. Applications routinely define their own headers to pass API keys, request IDs, or rate-limit data. Because a client can set most request headers to any value, servers should never treat a header like User-Agent as proof of identity.