HTTP Headers: What They Are and How They Work

Http Headers

HTTP headers carry metadata with every request and response. They tell the browser and server how to process data, what format it is in, how to cache it, who is allowed to access it, and much more. Understanding headers is fundamental to web development, API design, and securing any application that communicates over HTTP.

What Are HTTP Headers

HTTP headers are key-value pairs included in both HTTP requests and responses. They appear before the message body and provide context about the communication, covering content type, encoding, authentication, caching rules, security policies, and connection management. Each header occupies its own line and follows the format Header-Name: value.

Headers give the two sides of an HTTP conversation everything they need to process the message correctly. Without them, a server receiving a request would not know what format the client expects in the response. A browser receiving a response would not know how long to cache it, whether it is safe to embed it in a frame, or which origins are permitted to read it via JavaScript. Headers carry all of this context invisibly alongside every transfer.

GET /tutorial HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en-GB
Authorization: Bearer abc123
User-Agent: Mozilla/5.0 (Firefox/110)
Cookie: session_id=xyz789

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Cache-Control: max-age=3600
Content-Length: 4096
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff

Types of HTTP Headers

HTTP headers are grouped into categories based on their purpose and where they appear in the request-response cycle. Some headers are only meaningful in requests, others only in responses, and some apply to both.

Most Important HTTP Headers

Most web developers interact with a core set of headers regularly. Understanding what each one does and when to use it covers the vast majority of real-world HTTP interactions.

Security Headers You Should Set

Security headers are response headers that instruct the browser to apply specific protections when handling your content. They are not enforced by default and must be explicitly included in your server's responses. Setting these headers correctly defends against some of the most common web attacks with minimal effort.

• Strict-Transport-Security (HSTS): Tells the browser to only connect to your domain over HTTPS, even if the user types an HTTP URL. Once seen, the browser enforces this policy for a period defined by max-age. Adding includeSubDomains extends the policy to all subdomains. Example: Strict-Transport-Security: max-age=31536000; includeSubDomains
• Content-Security-Policy (CSP): Defines which sources of scripts, styles, images, and other resources the browser is permitted to load. A well-configured CSP is one of the most effective defences against cross-site scripting (XSS) attacks. Example: Content-Security-Policy: default-src 'self'; script-src 'self'
• X-Frame-Options: Prevents your page from being embedded inside an iframe on another domain, protecting users from clickjacking attacks where a hidden frame tricks them into clicking something they did not intend to. Example: X-Frame-Options: DENY
• X-Content-Type-Options: Prevents browsers from MIME sniffing, meaning guessing the content type from the response body when the Content-Type header is missing or ambiguous. This prevents certain content injection attacks. Example: X-Content-Type-Options: nosniff
• Referrer-Policy: Controls how much referrer information is included in the Referer header when navigating away from your site. Limiting this protects user privacy and prevents leaking sensitive URL parameters to third parties. Example: Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: Restricts which browser features and APIs your page is allowed to use or allow in embedded frames, such as the camera, microphone, geolocation, and payment request APIs. Example: Permissions-Policy: geolocation=(), microphone=()

How to View HTTP Headers

You can inspect HTTP headers for any request and response directly in your browser without any additional tools.

• Browser DevTools Network tab: Open DevTools with F12 or right-click and Inspect, then navigate to the Network tab. Reload the page and click any request in the list. The Headers panel shows the full request and response headers for that resource.
• curl on the command line: Run curl -I https://example.com to fetch only the response headers for a URL. Add -v for verbose output that shows both request and response headers together.
• Online header checkers: Tools like securityheaders.com analyse your domain's response headers and flag missing or misconfigured security headers with specific recommendations.

# Fetch only response headers
curl -I https://example.com

# Fetch headers and body with verbose output
curl -v https://example.com

# Send a custom request header
curl -H "Authorization: Bearer abc123" https://api.example.com/data

Frequently Asked Questions

1. Are HTTP header names case sensitive?
   Header names are case-insensitive under the HTTP/1.1 specification, so Content-Type and content-type are treated identically. HTTP/2 requires header names to be sent in lowercase. Header values may or may not be case-sensitive depending on the specific header. For consistency and compatibility, using the conventional capitalisation for each header name is recommended even though it is not strictly required.
2. Can I add custom headers to my API?
   Yes. You can include any custom header in your HTTP requests and responses. Historically, custom headers were prefixed with X-, for example X-API-Key or X-Request-ID, to distinguish them from standard headers. This convention is no longer formally required by modern standards but remains widely used. If you expose custom headers in a cross-origin API response, you must explicitly list them in Access-Control-Expose-Headers so that JavaScript running in the browser can read them.
3. What is CORS and how are its headers set?
   CORS (Cross-Origin Resource Sharing) is a browser security mechanism controlled entirely through HTTP response headers. The most important is Access-Control-Allow-Origin, which specifies which origins may read the response. Other CORS headers control which HTTP methods and request headers are permitted, whether credentials can be included, and how long the preflight response can be cached. CORS headers are set by the server, not the client. See the CORS guide for a complete breakdown.
4. What is the difference between the Host header and the URL domain?
   The URL domain is what you type in the browser address bar and is used to perform the DNS lookup and establish the connection. The Host header is sent inside the HTTP request and tells the server which virtual host or domain the request is intended for. On servers that host multiple websites at the same IP address, the Host header is how the server knows which site to serve. In HTTP/1.1 the Host header is mandatory. Without it, a server hosting multiple domains cannot determine which one to respond with.
5. Why do some headers start with X- and what does it mean?
   The X- prefix was historically used to mark headers as custom or non-standard extensions to the HTTP specification. Examples include X-Forwarded-For, which identifies the original client IP when requests pass through a proxy, and X-Request-ID, used for request tracing. In 2012, RFC 6648 deprecated the convention of using X- for new headers, recommending that custom headers simply be given descriptive names without the prefix. Many older headers with the prefix remain in wide use, but new custom headers no longer need it.

Conclusion

HTTP headers are the control layer of web communication. They handle authentication, caching, content formatting, security policies, and cross-origin access on every single request and response that travels across the web. Understanding the most commonly used headers, knowing which security headers to include on your server responses, and being able to inspect headers in DevTools or with curl gives you the visibility and control needed to build, debug, and secure web applications effectively. Continue with HTTP vs HTTPS, CORS, and HTTP caching to build a complete understanding of how HTTP works in practice.