What Are HTTP Headers?

Introduction

Whenever an HTTP request or response travels between a client and a server, it carries more than just a URL, method, status code, and body. It also carries additional metadata called HTTP headers. These headers describe how the message should be interpreted, who is sending it, what format is being sent, what format is expected in return, whether authentication is present, whether caching is allowed, whether compression is supported, whether cookies should be stored, and whether security rules should be enforced.

For API testers, HTTP headers are not minor technical details. They are part of the API contract. A request with the correct endpoint and correct JSON body can still fail if the Content-Type header is missing. A protected API can reject a request if the Authorization header is absent or expired. A response can be technically successful but still wrong if it returns the incorrect Content-Type, exposes unnecessary server information, misses security headers, or sets unsafe caching rules for private data.

Understanding headers helps testers diagnose API failures faster. It also helps developers design APIs that communicate clearly and securely. In real projects, many API bugs are not caused by the payload alone. They are caused by missing, incorrect, inconsistent, or unsafe headers. This tutorial explains HTTP headers from a practical API testing point of view, covering request headers, response headers, representation headers, authentication, content negotiation, caching, cookies, compression, security, common mistakes, and interview-ready explanations.

What Are HTTP Headers?

HTTP headers are key-value pairs included in HTTP requests and HTTP responses. They carry metadata about the message. A header has a name, a colon, and a value. For example, Content-Type: application/json tells the receiver that the message body is JSON. Authorization: Bearer abc123 sends authentication credentials. Cache-Control: no-cache gives caching instructions.

A simple definition is this: HTTP headers are key-value pairs that carry metadata about an HTTP request or response. They tell the client and server how to interpret, process, secure, cache, compress, and manage the communication.

Headers make HTTP communication intelligent. Without headers, the server would not reliably know the format of the submitted data. The client would not reliably know the format of the response. Authentication information would not have a standard place. Cookies and sessions would be difficult to manage. Caching and compression would be limited. Security policies would be harder to enforce. Headers provide the supporting information that allows a simple request-response protocol to power modern web applications, mobile apps, APIs, microservices, and browser experiences.

Why HTTP Headers Are Needed

Headers are needed because the body alone does not explain everything about a request or response. A JSON body may look like structured data, but the server should not guess that it is JSON. The client should explicitly send Content-Type: application/json. A client may want JSON back, but the server should not assume that unless the client sends an Accept header or the API contract defines JSON as the only supported response format.

Authentication also depends heavily on headers. Modern APIs commonly use bearer tokens, API keys, Basic authentication, session cookies, or custom authentication schemes. These values are usually carried through headers such as Authorization, Cookie, or platform-specific headers. If the header is missing, malformed, expired, or sent to the wrong domain, the request may fail even when the URL and body are correct.

Headers also support performance. Cache-Control, ETag, If-None-Match, Last-Modified, and If-Modified-Since help avoid downloading unchanged resources. Accept-Encoding and Content-Encoding help clients and servers use compression such as gzip or Brotli. These headers reduce bandwidth, improve response time, and reduce server load.

Security is another major reason headers matter. Browser-facing responses may include headers such as Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, and cookie attributes such as HttpOnly, Secure, and SameSite. These headers help protect users from downgrade attacks, content sniffing, clickjacking, cross-site scripting, and unsafe cookie behavior.

HTTP Request Structure

An HTTP request has a request line, headers, a blank line, and an optional request body. The request line contains the method, path, and HTTP version. The headers appear below the request line. The blank line separates headers from the body. If the request sends data, such as JSON for a POST request, the body appears after the blank line.

A typical request may look like this:

POST /login HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer abc123
Accept: application/json

{
  "username": "john",
  "password": "password123"
}

In this example, the request line is POST /login HTTP/1.1. The headers are Host, Content-Type, Authorization, and Accept. The blank line separates the headers from the JSON request body. The server uses the headers to understand the target host, body format, authentication credentials, and expected response format.

For API testing, this structure is important because a failure may occur in any part of the request. The endpoint path may be correct, but the method may be wrong. The method may be correct, but the headers may be missing. The headers may be correct, but the body may be invalid. A disciplined tester checks the complete request, not only the payload.

HTTP Response Structure

An HTTP response has a status line, headers, a blank line, and an optional response body. The status line contains the HTTP version, status code, and status text. The headers describe the response. The blank line separates headers from the body. The body contains the returned data when a body is applicable.

A typical API response may look like this:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 125
Cache-Control: no-cache

{
  "status": "success"
}

Here, the status line is HTTP/1.1 200 OK. The response headers tell the client that the body is JSON, the response length is 125 bytes, and caching should not be used. The body contains the result. If the response were 204 No Content, the headers might still exist, but there should be no response body.

Response headers are a key part of validation. A tester should verify that the API returns the expected Content-Type, does not cache private data incorrectly, includes required trace headers, handles cookies safely, and avoids exposing unnecessary server information. Many production issues are caused by successful status codes paired with unsafe or incorrect headers.

Header Format

Every HTTP header follows the same basic format: a header name, a colon, and a header value. For example:

Content-Type: application/json

The header name is Content-Type. The header value is application/json. Header names are case-insensitive in HTTP, which means Content-Type, content-type, and CONTENT-TYPE refer to the same header. However, teams should still use consistent formatting because it improves readability in logs, documentation, and test reports.

Some headers can appear more than once, while others should be combined or treated as single values depending on HTTP rules and client behavior. For example, cookies are often handled through repeated Set-Cookie headers. API testing tools may display repeated headers differently, so testers should understand how their tools represent them.

Whitespace and formatting can matter in practice. Extra spaces, malformed values, missing colons, incorrect quote usage, or invalid token format can cause parsing errors. For authentication headers, a small formatting mistake such as missing the word Bearer can turn a valid token into an invalid request.

Types of HTTP Headers

HTTP headers can be grouped by purpose. The common categories are request headers, response headers, general headers, and representation headers. This grouping helps testers understand where a header belongs and what it controls.

Request headers are sent by the client to describe the request. They may include Host, Authorization, Accept, Content-Type, User-Agent, Accept-Language, and Cookie. These headers tell the server who is making the request, what format the client is sending, what response format the client expects, and what session or authentication context applies.

Response headers are sent by the server to describe the response. They may include Content-Type, Content-Length, Date, Server, Cache-Control, Set-Cookie, and ETag. These headers tell the client how to interpret the response, whether it can be cached, whether cookies should be stored, and sometimes which resource version was returned.

General headers can apply to request and response messages. Examples include Connection, Cache-Control, Date, and Via. Representation headers describe the body representation being transferred, such as Content-Type, Content-Length, Content-Encoding, and Content-Language.

Request Headers

Request headers provide information about the client request. They influence how the server processes the message. A request may include authentication credentials, preferred response format, request body format, language preference, compression support, client application identity, and cookies.

For example:

GET /users HTTP/1.1
Host: api.example.com
Authorization: Bearer xyz123
Accept: application/json
User-Agent: PostmanRuntime/7.39.0

The Host header identifies the target server. The Authorization header sends credentials. The Accept header asks for JSON. The User-Agent identifies the client application. In a real system, these values can affect routing, authentication, response format, logging, analytics, and security rules.

API testers should verify required request headers for every protected or structured endpoint. A POST request with JSON should include the correct Content-Type. A secured endpoint should include valid authentication. A content-negotiated endpoint should handle Accept correctly. If the application uses tenant headers, correlation IDs, idempotency keys, or feature flags, those headers should be tested carefully because they may affect business behavior.

Response Headers

Response headers provide information about the server response. They help the client interpret the body, manage caching, store cookies, trace requests, and apply security behavior. A response can have a correct status code and body but still be defective because of incorrect response headers.

For example:

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 120
Cache-Control: no-cache
ETag: "user-101-v1"

{
  "id": 101,
  "name": "John"
}

The response tells the client that the body is JSON, gives the body length, prevents caching, and provides an ETag representing the returned version. If this response creates a resource, it may also include a Location header pointing to the new resource. If it starts or updates a session, it may include Set-Cookie.

Testing response headers includes validating expected values, missing headers, unsafe headers, and inconsistent headers across endpoints. For example, private account responses should not be publicly cached. JSON APIs should not return text/html for normal JSON responses. Authentication cookies should include secure attributes. Error responses should use the same content type and traceability headers as success responses unless the contract says otherwise.

Most Common HTTP Headers

The Host header specifies the destination server. It is especially important when multiple domains or applications are hosted on the same IP address. In API testing, incorrect Host behavior may appear behind gateways, proxies, or virtual hosts.

The Content-Type header indicates the format of the request or response body. Common values include application/json, application/xml, text/plain, multipart/form-data, and application/pdf. If a client sends JSON without Content-Type: application/json, the server may reject or misinterpret the body.

The Accept header specifies the response format expected by the client. A client may send Accept: application/json. If the server supports only JSON and the client requests XML, the server may return 406 Not Acceptable, depending on the API contract.

The Authorization header carries authentication credentials. A common example is Authorization: Bearer eyJhbGc.... This header is sensitive and should be protected carefully. It should not be logged casually, exposed in frontend error messages, or sent to untrusted redirect targets.

The User-Agent header identifies the client application. It may show a browser, mobile app, SDK, command-line client, or API testing tool. Some systems use it for analytics, compatibility behavior, or traffic filtering.

Content-Length specifies the size of the message body. Cache-Control controls caching behavior. Cookie sends session data from the client. Set-Cookie creates or updates cookies from the server. Accept-Encoding tells the server which compression algorithms the client supports. Content-Encoding tells the client which compression was used for the response.

Content-Type and Accept

Content-Type and Accept are often confused, but they solve different problems. Content-Type describes the format of the message body being sent. Accept describes the format the client wants to receive.

For example, in a POST request:

Content-Type: application/json
Accept: application/json

The first header says the request body is JSON. The second says the client expects a JSON response. If the request body is JSON but the Content-Type says XML, the server may reject the request with 415 Unsupported Media Type or fail to parse it. If the client requests XML through Accept but the API supports only JSON, the server may return 406 Not Acceptable.

In API testing, validate both. Do not assume they are interchangeable. A request without a body may not need Content-Type. A response without a body, such as 204 No Content, may not need a meaningful Content-Type. But for endpoints that send or receive data, these headers are central to correctness.

Authorization Headers

The Authorization header is one of the most important request headers in API testing. It carries credentials that allow the server to authenticate the client. Common schemes include bearer tokens, Basic authentication, API keys, and custom authorization formats. A typical bearer token header looks like this:

Authorization: Bearer abc123

Authentication testing should cover missing headers, malformed headers, invalid tokens, expired tokens, revoked tokens, wrong token type, wrong audience, wrong issuer, and valid tokens with insufficient permissions. Missing or invalid authentication should usually produce 401 Unauthorized. Valid authentication with insufficient permission should usually produce 403 Forbidden.

Security around authorization headers matters. Tokens should be sent over HTTPS. They should not be stored in logs, screenshots, reports, or downloadable artifacts without masking. They should not be included in URLs because URLs are commonly stored in browser history, logs, and analytics tools. If redirects occur, clients should avoid sending sensitive authorization headers to untrusted domains.

Cookies and Session Headers

Cookies are commonly managed through Cookie and Set-Cookie headers. The client sends cookies using the Cookie header. The server creates or updates cookies using Set-Cookie. Cookies are heavily used in browser-based applications, session management, login flows, CSRF protection, personalization, and tracking preferences.

A server response may include:

Set-Cookie: sessionId=XYZ456; HttpOnly; Secure; SameSite=Lax

The cookie value stores session information or a session reference. The HttpOnly attribute helps prevent JavaScript from reading the cookie. The Secure attribute tells browsers to send it only over HTTPS. The SameSite attribute helps control cross-site cookie behavior.

API testers should validate cookie creation, expiration, renewal, logout behavior, security attributes, and cross-site behavior where relevant. If a logout API returns success but does not expire the session cookie, the user may remain authenticated. If a session cookie lacks Secure or HttpOnly, the application may be weaker against common attacks.

Caching Headers

Caching headers control whether clients, browsers, proxies, and CDNs can store responses. Important caching headers include Cache-Control, ETag, Last-Modified, If-None-Match, and If-Modified-Since. Correct caching improves performance, but incorrect caching can expose private data or serve stale information.

Cache-Control: no-store tells clients not to store the response. This is useful for sensitive data such as account information. Cache-Control: no-cache means the cached response must be revalidated before use. ETag gives a version identifier for a resource. A client can send If-None-Match with that value later. If the resource has not changed, the server may return 304 Not Modified.

Testing caching headers requires multiple requests. First, request the resource and capture the caching headers. Then send a conditional request. Verify whether the server returns the expected 304 or a fresh 200 response. Also verify that private user-specific data is not cached publicly. A caching bug can be both a performance issue and a security issue.

Compression Headers

Compression reduces response size. The client uses Accept-Encoding to tell the server what compression formats it supports, such as gzip or br. The server uses Content-Encoding to tell the client which compression was applied.

Accept-Encoding: gzip, br
Content-Encoding: gzip

Compression improves performance for large responses, but it must be implemented correctly. If the server says the response is gzip-compressed but sends plain text, the client may fail to decode it. If the server compresses already-compressed media files unnecessarily, it may waste CPU. If compression is applied to sensitive data in risky contexts, teams may need to review security implications.

API testers should verify that compression works for large responses, that clients can decode compressed responses, that headers correctly describe the body, and that performance improves without breaking compatibility.

Security Headers

Security headers are especially important for browser-facing APIs and web pages, but API testers should still understand them. Strict-Transport-Security tells browsers to use HTTPS for future requests. X-Content-Type-Options: nosniff helps prevent MIME sniffing. X-Frame-Options can help prevent clickjacking. Content-Security-Policy controls which resources a browser may load and execute.

For APIs that only serve machine clients, some browser security headers may be less relevant. For APIs used by frontend applications, login flows, downloadable content, or embedded browser contexts, they can matter. Cookie security attributes are also essential for browser-based authentication.

Testing security headers involves verifying presence, correctness, consistency, and environment behavior. A staging environment may have different domains from production, but security rules should still be realistic. Missing security headers may not break functional tests, but they can create security findings.

Complete Request and Response Example

A complete API request to create a user may look like this:

POST /users HTTP/1.1
Host: api.example.com
Authorization: Bearer abc123
Content-Type: application/json
Accept: application/json
User-Agent: PostmanRuntime/7.39

{
  "name": "John"
}

A matching response may look like this:

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 120
Cache-Control: no-cache
Location: /users/101

{
  "id": 101,
  "name": "John"
}

In this example, the request headers identify the host, authentication, request format, expected response format, and client tool. The response headers identify the returned format, body size, caching instruction, and location of the created resource. A good test validates the status code, response body, and relevant headers together.

Request Headers vs Response Headers

Request headers are sent by the client. Response headers are sent by the server. Request headers describe what the client is sending and what it expects. Response headers describe what the server is returning and how the client should handle it.

For example, the client sends Authorization to prove identity, while the server may send Set-Cookie to establish a session. The client sends Accept to request JSON, while the server sends Content-Type to confirm JSON was returned. The client sends If-None-Match to ask whether a cached resource changed, while the server sends ETag to identify the resource version.

Understanding the direction of headers helps testers write clearer test cases. A test should not expect Authorization as a response header in a normal bearer-token API unless the contract explicitly returns a token. Similarly, a test should not expect Set-Cookie in a request; that header belongs to the server response.

Why Headers Matter in API Testing

Headers affect authentication, authorization, data format, content negotiation, security, performance, caching, compression, sessions, tracing, and client compatibility. An API can fail because a required header is missing even when the payload is correct. It can also appear to work while violating security or caching expectations.

In request testing, verify Authorization, Content-Type, Accept, Host, User-Agent, custom tenant headers, idempotency keys, correlation IDs, and any domain-specific headers your API requires. In response testing, verify Content-Type, Content-Length, Cache-Control, Date, ETag, Location, Set-Cookie, and security headers where applicable.

Error responses should also have correct headers. A validation error should not suddenly return HTML if the API contract promises JSON. A 401 response may include authentication challenge information depending on the scheme. A 429 response may include retry guidance. A 201 response may include Location. Headers and status codes often work together.

API Testing Checklist

A practical request-header checklist starts with authentication. Is the Authorization header required? What happens when it is missing, expired, malformed, or valid but insufficient? Next, check content headers. Is Content-Type required for body requests? Does the API reject unsupported media types? Does Accept influence the response format?

For response headers, verify the response content type, cache controls, body length behavior, date, ETag, Location, and cookie behavior. If the API returns downloadable files, verify Content-Disposition, file type, and file size expectations. If the API supports CORS, verify Access-Control-Allow-Origin and related headers according to security requirements.

For security headers, verify HTTPS-related headers, cookie attributes, content sniffing prevention, frame restrictions, and content security policy when relevant. For tracing, verify request ID or correlation ID propagation. For performance, verify compression and caching behavior. The exact checklist depends on the endpoint, but the habit is consistent: treat headers as part of the contract.

Real-World Example

Suppose a user logs into a streaming application. The client sends a login request with Content-Type: application/json because the username and password are submitted as JSON. The server validates the credentials and returns a token or creates a secure session cookie. Future API requests include the token in the Authorization header or include the session cookie automatically.

If the Authorization header is missing in a later request, the profile API returns 401 Unauthorized. If the token is valid but the user tries to access an admin endpoint, the API returns 403 Forbidden. If the response contains private profile data, it should not be cached publicly. If a cookie is used, it should be Secure, HttpOnly, and configured with an appropriate SameSite value.

This example shows how headers connect multiple parts of API behavior. They are involved in login, authentication, authorization, session handling, content type, caching, and security. Testing only the request body would miss most of the real contract.

Common Mistakes

A common mistake is sending JSON without Content-Type: application/json. Some servers may guess correctly, but reliable APIs should not depend on guessing. If the header is missing, the server may reject the request or parse it incorrectly.

Another mistake is confusing Content-Type with Accept. Content-Type describes what is being sent. Accept describes what the client wants back. Using one in place of the other can cause parsing or content-negotiation defects.

A third mistake is logging sensitive headers. Authorization tokens, cookies, API keys, and session identifiers should be masked in logs, reports, screenshots, and exported files. Test automation should be careful not to print secrets into CI logs.

Another mistake is ignoring response headers during validation. A test may pass because the status code and body are correct, while the API returns unsafe caching headers or missing security attributes. This is why header checks should be part of important API test cases.

Teams also sometimes return inconsistent headers across success and error responses. A success response may return JSON while an error response returns HTML from a proxy or application server. This breaks client expectations and should be caught in testing.

Best Practices

Always send the correct Content-Type when a request body is present. Use Accept when the client expects a specific response format. Protect sensitive headers such as Authorization, Cookie, API keys, and custom secrets. Use HTTPS to protect header data in transit.

Keep response headers consistent. Return the correct Content-Type for success and error responses. Use appropriate Cache-Control headers, especially for private or sensitive data. Include Location headers for resource creation when the API contract expects them. Use ETag and conditional request headers when caching and concurrency require them.

Validate mandatory headers during API testing. Do not assume headers are correct because the body looks right. Include header checks in automated tests for authentication, content negotiation, file download, caching, security, rate limiting, and asynchronous workflows.

Avoid exposing unnecessary server information. The Server header and framework-generated error pages can reveal implementation details. Security-conscious teams often minimize or standardize such information.

Interview-Ready Explanation

HTTP headers are key-value pairs included in HTTP requests and responses that carry metadata about the communication. They provide information such as content type, authentication credentials, accepted response formats, caching instructions, cookies, compression, language preferences, client details, server details, and security policies.

Request headers are sent by the client and include examples such as Authorization, Content-Type, Accept, Host, User-Agent, and Cookie. Response headers are sent by the server and include examples such as Content-Type, Content-Length, Cache-Control, Set-Cookie, ETag, and Date.

In API testing, headers are important because they affect authentication, authorization, request parsing, response format, caching, security, sessions, and performance. A tester should validate both request and response headers because incorrect headers can cause API failures even when the endpoint and payload are correct.

Key Takeaway

HTTP headers are the metadata layer of HTTP communication. They explain how a request or response should be interpreted, secured, cached, compressed, authenticated, and processed. They are not optional background details; they are part of the API contract.

For API testers, the practical rule is simple: validate headers whenever they affect behavior. Check Content-Type, Accept, Authorization, cookies, caching, compression, security, Location, ETag, and custom headers according to the endpoint's purpose. Strong header validation makes API tests more realistic, improves defect detection, and helps teams build APIs that are easier to consume and safer to operate.