HTTP Headers Explained: What Every Developer Needs to Know

Every time your browser loads a web page, sends a form, or calls an API, it's exchanging HTTP headers behind the scenes. These headers carry critical metadata about requests and responses — content types, caching policies, authentication credentials, security rules, and more. Understanding HTTP headers is essential for debugging, performance tuning, and building secure web applications.

What Are HTTP Headers?

HTTP headers are key-value pairs sent at the beginning of every HTTP request and response. They're invisible to end users but are used by browsers, servers, CDNs, and proxies to determine how to handle the associated data. Headers are separated from the body by a blank line.

GET /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept: application/json
Content-Type: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Content-Type — Tell the World What You're Sending

The Content-Type header tells the recipient the media type (MIME type) of the body being sent. This applies to both requests (what you're sending to the server) and responses (what the server is sending back).

Content-Type: application/json
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data
Content-Type: text/html; charset=UTF-8
Content-Type: text/plain
Content-Type: image/webp

Getting Content-Type wrong is a common source of bugs. If you send JSON to an API but set Content-Type: text/plain, many servers will refuse to parse the body and return a 415 Unsupported Media Type error.

Cache-Control — Control How Long Responses Are Cached

The Cache-Control header is one of the most important performance headers. It tells browsers and CDNs how long to cache a response and under what conditions:

• no-cache — Must revalidate with the server before using a cached version.
• no-store — Never store the response in any cache.
• max-age=31536000 — Cache for up to 1 year (for versioned static assets).
• public — Any cache (browser, CDN, proxy) may cache this response.
• private — Only the user's browser may cache this. Use for personalised content.
• immutable — Combined with max-age, browsers won't revalidate during the max-age window.

Authorization — Authenticate API Requests

The Authorization header carries credentials to authenticate an HTTP request. The two most common schemes:

• Bearer Token — Used with JWTs and OAuth 2.0: Authorization: Bearer <token>
• Basic Auth — Username and password encoded in Base64: Authorization: Basic <base64(user:pass)>

Note that Basic Auth encodes credentials in Base64, which is not encryption. Always use Basic Auth over HTTPS only. JWTs and Bearer tokens are the modern standard for API authentication.

CORS Headers — Control Cross-Origin Requests

Cross-Origin Resource Sharing (CORS) headers allow servers to explicitly state which external origins are permitted to make browser-based requests to their API. Without these headers, browsers block cross-origin requests by default:

Access-Control-Allow-Origin: https://yourapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

A common mistake is using Access-Control-Allow-Origin: * together with Access-Control-Allow-Credentials: true — this is invalid and browsers will block the request. If you need credentials, you must specify an exact origin.

Security Headers — Protect Your Users

Several HTTP headers are specifically designed to protect users from common web attacks:

• Content-Security-Policy — Specifies which sources of scripts, styles, and resources are trusted. Prevents XSS attacks.
• X-Frame-Options: DENY — Prevents clickjacking by blocking your page from being embedded in an <iframe>.
• Strict-Transport-Security — Forces browsers to always use HTTPS for your domain.
• X-Content-Type-Options: nosniff — Prevents browsers from treating files as a different MIME type than declared.
• Referrer-Policy: strict-origin-when-cross-origin — Controls how much referrer information is sent with navigation requests.

ETag and Last-Modified — Conditional Caching

ETag and Last-Modified headers enable conditional HTTP requests — a caching mechanism that lets the server tell the browser "your cached version is still fresh, no need to re-download". When a browser has a cached resource, it sends the ETag back in an If-None-Match request header. If the resource hasn't changed, the server responds with 304 Not Modified — no body is sent, saving bandwidth.

Accept-Encoding — Compressed Responses

The Accept-Encoding request header tells the server which compression algorithms the client supports. The server can then compress the response body before sending it:

# Client tells server what compression it supports:
Accept-Encoding: gzip, deflate, br

# Server confirms it compressed the response with Brotli:
Content-Encoding: br

Brotli (br) compresses 15–25% better than GZIP for text files (HTML, CSS, JS). Enable it on your server for significant bandwidth savings, especially for JavaScript bundles.