Skip to content
EN
Get Started

HTTP Headers

HTTP headers are name-value fields sent with web requests and responses. They describe the client, content, credentials, caching and how each message should be handled.

Table of Contents (8 sections)

How HTTP headers work

In HTTP/1.1, a message starts with a request or status line, followed by headers. Each header has a field name, a colon and a value. Field names are case-insensitive, though some values are case-sensitive.

HTTP/2 and HTTP/3 encode headers in frames. They use pseudo-headers such as :method and :status instead of textual start lines.

GET /products HTTP/1.1
Host: example.com
User-Agent: ExampleClient/1.0
Accept: application/json
Cookie: session=abc123

These request headers identify the target host, client, accepted response format and session. Response headers such as Content-Type, Cache-Control and Set-Cookie describe the returned data and how the client should handle it.

Common HTTP headers

  • Host: identifies the target host and lets one server handle multiple websites.
  • User-Agent: identifies the client software and version. See User Agent.
  • Accept and Content-Type: Accept requests a response format, while Content-Type describes the body being sent.
  • Cookie and Set-Cookie: send stored session values and save new ones. See Cookie.
  • Authorization and Proxy-Authorization: carry credentials for the website and proxy respectively. They aren’t interchangeable in proxy authentication.

Authentication tokens and session cookies are sensitive. Don’t expose them in logs, screenshots or error reports.

Headers vs body

Headers Body
Purpose Metadata and handling rules Content or submitted data
HTTP/1.1 position After the start line After the blank line
Examples Cache rules and content type HTML, JSON or image bytes

A request or response can have headers without a body. For example, a HEAD response returns headers describing a resource but doesn’t include its content.

How proxies handle headers

With plain HTTP, an HTTP proxy can read and may modify headers. With HTTPS through a CONNECT tunnel, the proxy normally sees the destination host and port but can’t read the encrypted HTTP headers. A reverse proxy or inspection gateway that terminates TLS can see them.

Sites often compare User-Agent, Accept-Language and client hints such as Sec-CH-UA during bot detection. A proxy changes the source IP that the site sees, but it doesn’t make inconsistent headers realistic. Use headers produced by your client, keep cookies consistent within a session and follow the site’s limits and terms.

FAQ

Are HTTP headers encrypted with HTTPS?

Yes. HTTPS encrypts headers and the body between the TLS endpoints. The destination domain may still be visible through DNS, TLS SNI or a proxy’s CONNECT request.

Can a proxy change HTTP headers?

Yes, if it can read the HTTP message. A plain HTTP proxy or gateway that terminates TLS can modify headers, while a proxy carrying an encrypted tunnel normally can’t.

Do HTTP headers reveal my real IP address?

Usually not. Browsers don’t normally put your public IP in a request header, but intermediaries may add fields such as Forwarded or X-Forwarded-For containing an address.

Related Terms

View All Terms