---
title: "What Are HTTP Headers? Common Headers Explained"
description: "HTTP headers are name: value lines sent before the body of every request and response. What they do, the common ones and how to view them in Chrome and curl."
url: https://proxynet.io/blog/what-are-http-headers
date: 2026-11-15
author: "Acar Diveroli"
category: "Proxies, Tutorial"
lang: en
---

# What Are HTTP Headers? Common Headers Explained

You open an online shop and it appears in your language, keeps you signed in and loads quickly from a cache. The page itself decided none of that. Before its first line arrives, your browser and the server exchange a dozen short lines about who is asking, what it accepts and what is coming back. Those lines are HTTP headers.

This post shows a real request and response captured with `curl`, the headers you will meet most, whether names are case-sensitive, and how to read headers in Chrome and with curl. It ends with security headers for site owners, the headers a proxy adds or reads, and six frequent questions.

> **Note: Short answer**
>
> HTTP headers are lines of the form `Name: value` sent at the start of every HTTP request and response, before the body. Request headers tell the server which site you want (`Host`), which browser you use (`User-Agent`), which formats and languages you accept, and carry your cookies and login tokens. Response headers tell the browser what kind of file is coming (`Content-Type`), how long it may be cached, which cookies to store and where to go next. Header names are not case-sensitive. You can read them in Chrome under DevTools > Network > Headers, or with `curl -I` and `curl -v`.

## What are HTTP headers?

HTTP headers are named pieces of extra information sent with a request or a response, before the content itself. RFC 9110, the standard that defines HTTP, calls the fields sent before the content "header fields", or simply headers. Each one is a line with a name, a colon and a value, such as `Accept-Language: en-GB`.

Every HTTP message has the same shape: a first line, the headers, one empty line, then the body if there is one. In a request the first line names the method and path (`GET /`); in a response it gives the status code (`200 OK`). The body is the page, image or data; the headers describe it and the two sides of the exchange.

Request headers go from your browser or app to the server, and response headers come back. MDN's [HTTP headers reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers) lists every standard header by group. Names starting with `X-` are home-made extensions; that naming habit was deprecated in 2012, but many such names are still in use.

## How does a request and response with headers work?

A page load is one request and one response, each with its own headers:

1. **Your browser connects to the server.** For an `https://` address it sets up encryption first.
1. **It sends the request line and request headers:** `GET /`, then `Host`, `User-Agent`, `Accept`, `Accept-Language` and any cookies for that site.
1. **An empty line ends the headers.** A form or an API call adds a body after it.
1. **The server reads the headers:** `Host` picks the site, `Accept-Language` the language, `Cookie` the signed-in user.
1. **It answers with a status line and response headers,** such as `200 OK` and `Content-Type`, then an empty line and the body.
1. **The browser acts on them:** it renders the page, stores cookies, caches a copy or follows a redirect.

## What does a real HTTP request and response look like?

Here is one exchange with example.com, made with `curl -v`. curl is a command-line tool that fetches web addresses and ships with Windows 10 and 11, macOS and most Linux systems; `-v` (verbose) prints both sides. We ran it on Windows 11 on 15 November 2026 and trimmed the output to the headers:

```text
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 15 Nov 2026 15:40:29 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: cloudflare
< last-modified: Thu, 12 Nov 2026 21:56:22 GMT
< allow: GET, HEAD
< Accept-Ranges: bytes
< Age: 6679
< cf-cache-status: HIT
< alt-svc: h3=":443"; ma=86400
```

Lines starting with `>` are what curl sent, lines starting with `<` what the server answered; the lone `>` is the empty line that ends the request headers. curl sends three request headers, a browser more than ten.

- **`Content-Type: text/html; charset=utf-8`:** the body is a web page in UTF-8 text.
- **`Age: 6679`:** the content delivery network in front of the site has held this copy for 6,679 seconds, about 1 hour 51 minutes.
- **`cf-cache-status: HIT`:** not a standard header, but that network's own note that the copy came from its cache.
- **`alt-svc: h3=":443"`:** the site also speaks HTTP/3 on port 443.

Notice `Content-Type` next to `last-modified`: one response, two ways of writing names.

## Are HTTP headers case-sensitive?

No, header names are not case-sensitive: `Content-Type`, `content-type` and `CONTENT-TYPE` are the same header. [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names) says it in one line: "Field names are case-insensitive." When we requested the same page over plain `http://`, the server even wrote `Last-Modified` and `Allow` with capitals.

Values follow each header's own rules. `text/html` and `TEXT/HTML` name the same file type, but a cookie value or a login token must go back exactly as the server sent it.

HTTP/2 and HTTP/3, the newer versions of the protocol, require lowercase names, which is why Chrome DevTools shows `content-type`. In our test, Chromium loaded example.com over HTTP/3, and its request began with `:method`, `:path`, `:scheme` and `:authority`. These pseudo-headers carry what HTTP/1.1 puts in the first line and the `Host` header.

In code, compare header names without regard to case. JavaScript's `Headers` object and Python's requests library already do; a plain dictionary does not.

## What are the most common request headers?

Request headers describe who is asking and what it will accept:

| Header | What it tells the server | Example value |
|---|---|---|
| Host | Which site you want | `example.com` |
| User-Agent | Browser or app and version | `curl/8.22.0` |
| Accept | File types you can use | `text/html` |
| Accept-Language | Languages you prefer | `en-GB,en;q=0.9` |
| Cookie | Cookies saved for this site | `theme=dark` |
| Authorization | Login for the site or API | `Bearer <token>` |
| Referer | Page you came from | `https://example.com/` |

**Host** lets one server and one IP address carry many websites: the server reads the name and picks the site. **Accept-Language** is how a site picks a language before you choose one; the `q` numbers are weights from 0 to 1, so `en-GB,en;q=0.9` means British English first, any English second.

**Cookie** carries back the small values a site stored earlier with `Set-Cookie`, such as a sign-in session ID. [What Are Cookies and What Are They Used For?](/blog/what-are-cookies) walks through that exchange step by step.

**Authorization** carries credentials for the site itself, often after a 401 Unauthorized response; the standard forbids a proxy to change it. **Referer**, misspelled in the standard, names the page that linked you here; for a link to another site, browsers send only the origin, such as `https://example.com/`, by default. Chrome also sends headers of its own, such as `sec-ch-ua`, a short list of browser brands and versions.

## What are the most common response headers?

Response headers tell the browser what it received and what to do with it:

| Header | What it tells the browser | Example value |
|---|---|---|
| Content-Type | Kind of file in the body | `application/json` |
| Cache-Control | Whether and how long to cache | `max-age=3600` |
| Set-Cookie | A cookie to store | `theme=dark; Secure` |
| Location | Address to go to next | `/login` |
| Retry-After | How long to wait | `120` |
| Strict-Transport-Security | Use only HTTPS from now on | `max-age=31536000` |

**Content-Type** decides what the browser does with the body: render `text/html`, show `image/png`, hand `application/json` to a script. A wrong value is why a page sometimes shows raw code. `Content-Disposition: attachment` asks the browser to download the file instead.

**Cache-Control** sets the caching rules: `max-age=3600` allows reuse for an hour, `no-store` forbids keeping a copy. **Set-Cookie** may appear many times in one response, one line per cookie. **Location** comes with redirects (the 3xx codes) and gives the new address.

**Retry-After** comes with 503 Service Unavailable and 429 Too Many Requests and says how long to wait, in seconds or as a date. `Retry-After: 120` means two minutes; a well-behaved client waits that long.

## How do you see HTTP headers in Chrome?

Chrome shows every header of every request in its Developer Tools (DevTools), in the Network panel:

1. Open the page and press **F12**, or **Ctrl + Shift + I** on Windows (**Cmd + Option + I** on a Mac). Right-clicking the page and choosing **Inspect** works too.
1. Click the **Network** tab. DevTools records only while it is open, so reload the page.
1. In the **Name** column, click the first row, the page itself.
1. Open the **Headers** tab. **General** shows the address, method and status code; below it come **Response headers** and **Request headers**.
1. Tick **Raw** next to a section to see the lines as they arrived, in their original order.

If you see "Provisional headers are shown", the file probably came from the browser's cache; tick **Disable cache** at the top of the panel and reload. Chrome's [Network panel reference](https://developer.chrome.com/docs/devtools/network/reference#headers) explains the other options, such as showing a header as a column.

To repeat a request outside the browser, right-click it and choose **Copy** > **Copy as cURL (cmd)** on Windows, or **Copy as cURL** on a Mac. The command includes your cookies and any login header, so never paste it into a public forum or chat.

## How do you see HTTP headers with curl?

curl shows headers from the command line, which is handy for checking your own site. Type the commands in Command Prompt; in Windows PowerShell, type `curl.exe`, because there `curl` names a different command.

```cmd
curl -I https://example.com
```

`-I` asks for the response headers only, with a `HEAD` request; our run printed the same response headers as above. Two other options:

- **`curl -v https://example.com`** shows the request headers, the response headers and connection details.
- **`curl -I -H "Accept-Language: de" https://example.com`** adds a header of your own, for example to test how your site answers a German-language browser.

Windows' built-in curl speaks HTTP/1.1 (its verbose output says `ALPN: curl offers http/1.1`), so you see names in whatever case the server wrote them. A curl build with HTTP/2 support prints them in lowercase for sites that speak HTTP/2.

## Which security headers should a website send?

Security headers are response headers that switch on extra browser protections for your site. You set them in the web server, the content delivery network or the application:

- **Strict-Transport-Security (HSTS):** use only HTTPS for this site for `max-age` seconds. Browsers ignore it over plain HTTP. Add `includeSubDomains` only once every subdomain works over HTTPS.
- **Content-Security-Policy (CSP):** lists where the page may load scripts, styles and images from, which limits what an injected script can do.
- **X-Content-Type-Options: nosniff:** the browser trusts `Content-Type` instead of guessing the file type.
- **X-Frame-Options**, or `frame-ancestors` in CSP: whether other sites may show your page in a frame, a defence against clickjacking (tricking visitors into clicking a hidden page).
- **Referrer-Policy:** how much of your page address goes into `Referer` when visitors leave.

Check your site with `curl -I` or under **Response headers** in DevTools. For sign-in cookies, the `Secure`, `HttpOnly` and `SameSite` flags inside `Set-Cookie` matter just as much.

## Which headers does a proxy add or read?

A proxy works with a few headers of its own: some it reads from you, some it may add before passing your request on.

- **`Proxy-Authorization`** carries your proxy login, such as `user:pass`, to the proxy, which uses it up instead of passing it to the site.
- **`Proxy-Authenticate`** comes with the proxy's `407 Proxy Authentication Required` reply when the login is missing or wrong.
- **`Via`** records that an intermediary handled the message; the HTTP standard says a proxy must add it.
- **`X-Forwarded-For`** and its standard form **`Forwarded`** carry the client's original IP address. [RFC 7239](https://www.rfc-editor.org/rfc/rfc7239), which defines `Forwarded`, says a proxy meant to provide anonymity will not use it.

Whether a proxy adds `Via` or `X-Forwarded-For` is what sorts proxies into transparent, anonymous and elite; [Transparent vs Anonymous vs Elite Proxies](/blog/anonymous-proxy-levels) shows the same request at all three levels.

With HTTPS, most of this disappears. For an `https://` address your app asks the proxy to open a tunnel with `CONNECT`, and from then on the proxy forwards encrypted bytes without reading them. We ran curl through a small test proxy on our own computer, with the placeholder login `user:pass`:

```text
> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> Proxy-Authorization: Basic dXNlcjpwYXNz
> User-Agent: curl/8.22.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*
```

The proxy's log recorded only the first block. The `GET` request and its headers travelled inside the encrypted tunnel, so the proxy could neither read them nor add lines. `dXNlcjpwYXNz` is simply `user:pass` in Base64, an encoding, not encryption.

That is how an [HTTPS Proxy](https://proxynet.io/https-proxy) carries your traffic: Proxynet's gateway relays the tunnel without decrypting it, so you install no certificate from us. A proxy changes the IP address the site sees; it is no reason to rewrite your own headers. Do not edit `User-Agent`, `Referer` or `X-Forwarded-For` to pose as another browser or visitor; scripts you run should send an honest `User-Agent` that names your tool.

## Where you meet HTTP headers

- **Language versions:** a site reads `Accept-Language` to choose the first page you see.
- **Signing in:** the `Cookie` header carries your session with every request.
- **APIs:** a token in `Authorization`, `Content-Type: application/json` for the body.
- **Caching:** `Cache-Control` and `Age` decide whether a stored copy is still fresh.
- **Downloads:** `Content-Disposition` decides whether a file opens or is saved.

## Common mistakes

- **Reading header names case-sensitively in code.** `headers["Content-Type"]` on a plain dictionary misses `content-type` from an HTTP/2 server.
- **Sharing a "Copy as cURL" command.** It carries your cookies, so anyone who has it can act as you.
- **Trusting `X-Forwarded-For` from the internet.** A client can send any value; only entries added by your own proxy or load balancer (the server that spreads traffic across your servers) are reliable.
- **Turning on HSTS with `includeSubDomains` too early.** A subdomain without HTTPS becomes unreachable for visitors who saw the header.
- **Letting cookies pile up.** Large cookies push the request past the server's header limit, and the site answers 400 or 431.

## Decision guide

| What you want | Where to look or what to use |
|---|---|
| See what your browser sends | DevTools > Network > Headers |
| Check a site's response quickly | `curl -I` |
| Find where a redirect goes | `Location` in the response |
| Find out why a page is in another language | `Accept-Language` in the request |
| Harden your own site | HSTS, CSP, nosniff, Referrer-Policy |
| Sign in to a proxy | `Proxy-Authorization`, set by your app |

## Frequently asked questions

### What is the User-Agent header?

It is the request header that names the browser or program making the request, with its version and usually the operating system; curl sends `curl/8.22.0`. Sites use it for statistics and to work around browser quirks. [What Is a User Agent? How to Check and Change It](/blog/what-is-user-agent) shows how to read yours.

### What does X-Forwarded-For mean?

It is a header in which a proxy or load balancer writes the IP address of the client that sent it the request, so the server behind it sees the visitor's address. It was never formally standardised; `Forwarded` (RFC 7239) is the standard version. Anyone can send it, so a server should trust only the entries its own proxy added.

### Are HTTP headers encrypted with HTTPS?

Yes. Over HTTPS, headers travel inside the encryption together with the body, so networks and proxies along the way cannot read them. The server's IP address stays visible and, in most cases, so does the domain name, which is sent while the connection is set up.

### What are HTTP headers in an API?

The same headers, used more deliberately. An API call usually sends a key or token in `Authorization` (some APIs use their own header, such as `X-API-Key`), declares the body with `Content-Type: application/json` and asks for JSON with `Accept`. Too many requests often get a 429 with `Retry-After`.

### What does "HTTP header is larger than 8192 bytes" mean?

It means a request or response carried more header data than the software handling it accepts. The wording comes from Netty, a Java networking library with a default limit of 8,192 bytes; other numbers, such as 10,240, are configured limits. HTTP itself sets no maximum. As a visitor, delete that site's cookies; as a developer, shrink the cookies or tokens, or raise the limit.

### Why is the Referer header misspelled?

Because the misspelled name was already in the HTTP/1.0 specification of 1996, and software everywhere reads it under that name. Today's standard keeps `Referer` with a "[sic]" note; the newer `Referrer-Policy` header is spelled correctly.

## Summary

HTTP headers are the `Name: value` lines at the start of every request and response. Request headers name the site, browser, languages, cookies and credentials; response headers say what the body is, how long to cache it, which cookies to store and where to go next. Names are not case-sensitive, and HTTP/2 and HTTP/3 write them in lowercase. Read them in DevTools or with curl, and send security headers from your own site. Over HTTPS a proxy sees only the short `CONNECT` request with the site name and your proxy login; to route your own traffic through one, start with our [proxy services](/proxy).