Every time your browser talks to a website, it sends more than just “give me this page.” Tucked alongside that simple request is a little bundle of extra information: what format you can accept, who you are, whether you’ve been here before, and a dozen other details. That bundle is made of HTTP headers, and once you understand them, a lot of web behavior that used to feel mysterious suddenly makes sense.
In this guide we’ll unpack what headers are, how request headers differ from response headers, and the handful of common ones you’ll meet again and again. No prior experience needed — we’ll define every term the moment it shows up.
What a header actually is
An HTTP message — whether it’s a request your browser sends or a response the server sends back — has two parts: a body (the actual content, like the HTML of a page or the data you submitted) and a set of headers that describe that content and the conversation around it.
A header is simply a key and a value separated by a colon. Think of it like a label on a shipping box. The box itself holds the goods (the body), but the label tells you the address, how fragile it is, and how it should be handled. Headers are those labels for web traffic.
Here’s roughly what a real request looks like when written out as plain text:
GET /articles HTTP/1.1
Host: blog.acy-partner.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: en-US
Connection: keep-aliveThe first line is the request itself (the method and path). Everything after it, up to the blank line, is headers — one per line, each in Key: Value form. The server reads these to decide how to respond.
Headers are not the body
Headers describe the message; they are not the content of it. When you submit a form, your name and email go in the body. Information about that submission — like its format and length — goes in the headers.
Request headers vs response headers
Both sides of the conversation use headers, but they say different things.
Request headers travel from the client (your browser, a mobile app, or a script) to the server. They mostly describe who is asking and what they can handle. For example, your browser announces which languages and formats it prefers so the server can tailor the reply.
Response headers travel back from the server to the client. They describe what is being sent and how to treat it — the format of the data, whether it can be cached, what cookies to store, and so on.
Here’s the round trip drawn out:
┌─────────┐ request + request headers ┌─────────┐
│ Browser │ ─────────────────────────────► │ Server │
│(client) │ ◄───────────────────────────── │ │
└─────────┘ response + response headers └─────────┘Some header names can appear in both directions, but most have a natural home on one side. Let’s look at the ones you’ll actually run into.
The common headers, explained
Content-Type
Content-Type tells the receiver what format the body is in, so it knows how to interpret those bytes. A web page comes back as text/html; an API often replies with application/json; an image might be image/png.
Content-Type: application/jsonThis header matters in both directions. When you send data to a server, your Content-Type tells it how to read your body. When the server replies, its Content-Type tells your browser whether it’s looking at a page to render, a file to download, or data to process.
A wrong Content-Type breaks things quietly
If a server labels JSON data as text/plain, the browser may treat it as raw text instead of structured data, and your code that expected JSON gets nothing useful. The header has to match the actual content.
Content-Length
Content-Length states the size of the body, in bytes. It lets the receiver know exactly how much data to expect, so it can tell when the message is complete.
Content-Length: 1024You rarely set this by hand — tools usually calculate it for you — but it’s good to recognize when you see it.
Authorization
Authorization is how a request proves who it is or that it’s allowed in. A very common pattern is a bearer token: a long string the server hands you after you log in, which you then attach to future requests.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Without this header, a protected endpoint will usually refuse to answer. Because it carries credentials, it should only ever travel over an encrypted connection (HTTPS), never plain HTTP.
User-Agent
User-Agent is a self-description the client sends about itself — the browser or program and its version. Servers sometimes use it to adjust their response, for example serving a mobile-friendly layout.
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)It’s informational and easily faked, so it’s never a security feature — just a hint.
Accept
Accept is the client politely saying which formats it would like back. The server tries to honor it but isn’t obligated to.
Accept: application/jsonIf you ask an API for application/json, a well-behaved server gives you JSON. Think of Accept as the request-side counterpart to the response’s Content-Type: one says “here’s what I’d prefer,” the other says “here’s what I actually sent.”
Cache-Control
Cache-Control governs caching — whether and how long a response may be stored and reused instead of fetched again. Caching makes sites faster by avoiding repeat downloads.
Cache-Control: max-age=3600, publicThat example says the response may be cached for 3600 seconds (one hour) and can be stored by shared caches. The opposite extreme, no-store, tells everyone to never keep a copy — useful for sensitive or always-changing data.
Set-Cookie
Set-Cookie is a response header where the server asks the browser to remember a small piece of data and send it back on future requests. This is how a site keeps you logged in across pages.
Set-Cookie: session_id=abc123; HttpOnly; SecureThe browser stores that cookie and automatically includes it (via a Cookie request header) on later requests to the same site. The HttpOnly and Secure flags above harden it: HttpOnly hides it from page scripts, and Secure only sends it over HTTPS.
Location
Location appears in redirect responses. When a server replies with a status code in the 3xx range — say, “this page has moved” — the Location header tells the browser where to go instead.
Location: https://blog.acy-partner.com/new-urlThe browser reads it and quietly makes a fresh request to that address, which is why you sometimes see the URL change on its own.
A quick reference table
Here are those headers side by side, with the direction you’ll usually find them and what they’re for.
| Header | Usually on | What it does |
|---|---|---|
Content-Type |
both | States the format of the body (HTML, JSON, image) |
Content-Length |
both | Size of the body in bytes |
Authorization |
request | Carries credentials, e.g. a bearer token |
User-Agent |
request | Identifies the client (browser/app) |
Accept |
request | Formats the client would like back |
Cache-Control |
both | Caching rules for the response |
Set-Cookie |
response | Asks the browser to store data |
Location |
response | Redirect target the browser should follow |
Seeing headers for yourself
You don’t need any special software to inspect headers. Open your browser’s developer tools (usually the F12 key), go to the Network tab, reload a page, and click any request in the list. You’ll see its request headers and response headers laid out exactly like the examples above.
From a terminal, a single command shows the response headers for a URL:
curl -I https://blog.acy-partner.comThe -I flag asks for headers only, no body. It’s a quick way to check things like the Content-Type and Cache-Control a site is actually sending.
Recap
Headers are the metadata of the web — small Key: Value labels attached to every request and response that describe the conversation without being part of the content itself. Here’s the shape of it:
- An HTTP message has a body (the content) and headers (the labels describing it).
- Request headers say who’s asking and what they can handle; response headers say what’s being sent and how to treat it.
- A few names cover most situations:
Content-TypeandContent-Lengthdescribe the body;Authorization,User-Agent, andAcceptride on requests;Cache-Control,Set-Cookie, andLocationshape responses.
Once headers click, the next natural step is the other piece of a response: status codes — those three-digit numbers like 200, 404, and 301 that tell you, at a glance, how a request turned out. Pair headers with status codes and you can read almost any HTTP exchange with confidence.
