HTTP Headers That Every Web Developer Should Know

HTTP headers control how browsers and servers interact. They handle essential tasks like identifying content type, managing authentication, setting cache policies, controlling redirects, and enforcing cross-origin rules. They also let developers customize how APIs respond in different scenarios.

This article explains the types of HTTP headers and how to work with them during development.

What Are HTTP Headers?

HTTP headers are key-value pairs sent between a browser and a server during every web request and response. They help both sides understand how to process the request or deliver the response.

Headers carry details such as the type of content being sent, how long it should be cached, what language is preferred, or whether the user is authorized to access the content. This additional context makes web communication more reliable, secure, and efficient.

Why are HTTP Headers Important in Web Development

Headers are critical in shaping how websites function, communicate, and protect user data. They help developers control behavior, enforce standards, and improve performance.

• Content Identification: Headers like Content-Type define what kind of data is being transferred. This helps the browser understand whether it should render HTML, parse JSON, or download a file.
• User Authentication: The Authorization header is used to send credentials or tokens that allow users to access secure parts of an application without needing to log in repeatedly.
• Caching and Load Management: Headers such as Cache-Control or ETag help browsers store and reuse content when possible. This reduces server load and improves page load times for repeat visitors.
• Access Control Across Domains: Cross-Origin Resource Sharing (CORS) headers specify which external websites are allowed to access your resources. This is essential for APIs and public content.
• Language and Encoding Preferences: Headers like Accept-Language or Content-Encoding let developers tailor the response based on user preferences or connection types, such as serving compressed content to save bandwidth.
• Request Tracing and Logging: Headers such as User-Agent or Referer provide information about where the request is coming from and what browser or device is being used. This helps in debugging, analytics, and personalization.

Types of HTTP Headers

HTTP headers are grouped based on when and how they are used during a request-response cycle. Understanding these categories helps organize headers correctly and avoid misconfiguration.

• General Headers: They contain information that isn’t specific to the content, such as connection status or caching policies, and apply to both requests and responses. For example, Cache-Control tells the browser how long it takes to cache the response.
• Request Headers: They tell the server what the client needs, supports, or prefers and are sent from the browser to the server. For example, Accept specifies preferred content types like JSON or HTML, and User-Agent identifies the browser and operating system.
• Response Headers: They are sent from the server to the browser and describe the response, such as its format or length. For example, Content-Type tells the browser how to interpret the data like HTML, JSON, or plain text.
• Entity Headers: They provide details about the body of the request or response, such as its size or encoding. For example, Content-Length shows how many bytes are in the body, and Content-Encoding indicates if the content is compressed.
• End-to-End Headers: These are passed unchanged from the client to the server or vice versa, no matter how many intermediaries are involved. For example, Authorization remains intact even when proxies are used.
• Hop-by-Hop Headers: These are processed only by a single transport-level connection and are not forwarded by proxies. For example, Connection controls whether the network connection stays open after the current transaction.

Common Request Headers

Request headers are sent by the browser to the server. They describe what the client can accept, who the user is, or how the request should be handled.

• Authorization: Used to send credentials like tokens or API keys so the server can verify the request. For example, a REST API might require Authorization: Bearer <token> to allow access to user data.
• Accept: Tells the server what type of content the client can handle. For example, Accept: application/json tells the server to return data as JSON instead of HTML.
• Accept-Encoding: Lists the compression formats the client supports. For example, Accept-Encoding: gzip, br allows the server to compress the response using gzip or Brotli to reduce size.
• Accept-Language: Specifies the preferred language for the response content. For example, en-US tells the server to return the response in U.S. English if it’s supported.
• User-Agent: Describes the browser and system making the request. For example, a mobile browser might send a User-Agent that helps the server serve a mobile-optimized layout.
• Referer and Referrer-Policy: Referer sends the URL of the previous page, often used in analytics or security filters. Referrer-Policy controls whether that information is sent, helping to reduce leakage of sensitive URLs.
• Cookie: Sends stored data like session IDs or user preferences from the browser to the server. For example, Cookie: session_id=abc123 allows a server to identify the user and maintain their session without requiring them to log in again.

Common Response Headers

When a server sends a response to the browser, it includes headers describing the content and how it should handle it. These headers control behavior like redirection, content type, and session management.

Here are some of the most commonly used response headers:

• Set-Cookie: Saves a cookie on the user’s device so the server can identify returning users or store session data. For example, Set-Cookie: session_id=abc123 helps the server recognize a logged-in user without asking them to log in again.
• Location: Tells the browser to redirect the user to a different URL. This is commonly used after form submissions or when access is restricted. For example, Location: /login sends the user to the login page if they try to access a restricted area.
• WWW-Authenticate: Instructs the browser to ask the user for credentials before accessing the resource. For example, WWW-Authenticate: Basic triggers a login prompt asking for a username and password.
• Content-Type: Describes the format of the returned content so the browser can handle it properly. For example, Content-Type: application/json tells the browser the response contains a JSON object.
• Content-Length: Specifies the size of the response body in bytes. This helps the browser know when the response has been fully received. For example, Content-Length: 4523 tells the browser to expect 4,523 bytes of data.
• Content-Encoding: Tells the browser how the content was compressed, so it knows how to decode it. For example, Content-Encoding: gzip tells the browser to unzip the data before displaying it.
• Content-Language: Indicates the language of the content returned by the server.
  For example, Content-Language: en-US means the content is in American English.
• Content-Disposition: Instructs the browser how to handle the response—whether to show it or download it.
  For example, Content-Disposition: attachment; filename=”invoice.pdf” triggers a download prompt for a PDF file.

Caching Headers

Caching headers help browsers and servers manage stored copies of resources. This reduces load times and server traffic by avoiding unnecessary downloads when the content hasn’t changed.

Below are some key headers used for cache control:

• Cache-Control: Defines caching rules like how long a response can be stored or if it must be revalidated. For example, Cache-Control: max-age=3600 allows the browser to reuse the response for one hour.
• Pragma: A legacy header that disables caching in HTTP/1.0. For example, Pragma: no-cache tells older browsers not to cache the response.
• Expires: Sets a specific date and time after which the response is considered stale. For example, Expires: Wed, 21 Jun 2025 07:28:00 GMT marks that date as the cache expiry time.
• ETag: Provides a unique identifier for a response version to check if content has changed. For example, ETag: “abc123” lets the browser ask the server if that version is still valid.
  Last-Modified: Indicates the last time the resource was changed. For example, Last-Modified: Tue, 11 Jun 2024 10:00:00 GMT helps the browser decide whether to fetch a fresh version.
• If-Modified-Since: Sent by the browser to check if the content has changed since a given date. For example, If-Modified-Since: Tue, 11 Jun 2024 10:00:00 GMT avoids downloading data if it hasn’t changed.
• Vary: Instructs the browser to cache different versions of the response based on header values. For example, Vary: Accept-Encoding tells the cache to store separate copies for gzip and non-gzip requests.
• Age: Shows how long the response has been stored in a proxy cache. For example, Age: 120 means the response has been cached for 120 seconds.
• Clear-Site-Data: Tells the browser to delete stored data like cache or cookies for the site. For example, Clear-Site-Data: “cache”, “cookies” removes all cached files and session data.

Security Headers

Security headers protect users from common web vulnerabilities. They guide the browser to enforce specific security rules that help prevent attacks like cross-site scripting (XSS), clickjacking, and mixed content. Below are the key headers used to strengthen a site’s security:

• Strict-Transport-Security: Forces the browser to use HTTPS instead of HTTP for all future requests. For example, Strict-Transport-Security: max-age=31536000 tells the browser to use HTTPS for the next year.
• Content-Security-Policy: Controls which sources the browser can load content from to reduce XSS risks. For example, Content-Security-Policy: default-src ‘self’ blocks resources from untrusted domains.
• X-Content-Type-Options: Prevents the browser from guessing the content type, which can block some attacks. For example, X-Content-Type-Options: nosniff ensures files are only interpreted as their declared types.
• X-Frame-Options: Controls whether the site can be embedded in an iframe to prevent clickjacking. For example, X-Frame-Options: DENY stops the site from being loaded in any iframe.
• X-XSS-Protection: Was used to enable built-in browser protection against reflected XSS attacks. For example, X-XSS-Protection: 1; mode=block tells the browser to block suspicious scripts (now deprecated in most modern browsers).
• Expect-CT: Tells browsers to enforce Certificate Transparency, improving SSL security.
  For example, Expect-CT: max-age=86400, enforce blocks certificates not listed in public logs.
• Cross-Origin-Resource-Policy: Restricts how other sites can load your resources to prevent data leaks. For example, Cross-Origin-Resource-Policy: same-origin ensures resources are only shared within the same origin.
• Feature-Policy (now Permissions-Policy): Limits access to browser features like camera or geolocation. For example, Permissions-Policy: camera=(), microphone=() blocks camera and mic access.
• Upgrade-Insecure-Requests: Asks the browser to upgrade HTTP resources to HTTPS automatically. For example, Upgrade-Insecure-Requests: 1 tells the browser to try HTTPS before loading any HTTP resources.

CORS Headers

CORS (Cross-Origin Resource Sharing) headers control how resources are shared between different origins. They help secure your application by defining which domains can access your APIs and under what conditions.

Below are the headers that manage CORS behavior:

• Access-Control-Allow-Origin: Specifies which origin is allowed to access the resource. For example, Access-Control-Allow-Origin: https://example.com allows requests only from that domain.
  Access-Control-Allow-Credentials: Indicates whether cookies or credentials can be included in the request. For example, Access-Control-Allow-Credentials: true lets the browser send cookies with the request.
• Access-Control-Allow-Headers: Lists the headers that are allowed to be requested by the client. For example, Access-Control-Allow-Headers: Authorization, Content-Type allows these two headers in requests.
• Access-Control-Allow-Methods: Specifies which HTTP methods are allowed when making cross-origin requests. For example, Access-Control-Allow-Methods: GET, POST, PUT lets the server accept those methods from permitted origins.
• Access-Control-Expose-Headers: Specifies which response headers can be read by JavaScript. For example, Access-Control-Expose-Headers: X-Custom-Header makes that header available in frontend code.
• Access-Control-Request-Headers: These are sent by the browser during a preflight request to check if custom headers can be included in the actual request. For example, Access-Control-Request-Headers: Authorization tells the server the client wants to send an Authorization header, which the server must approve in the CORS policy.
• Access-Control-Request-Method: Sent by the browser to ask which HTTP method it can use. For example, Access-Control-Request-Method: PUT is used before sending the actual PUT request.
• Origin: Identifies the request’s source so the server can decide whether to allow it. For example, Origin: https://example-client.com shows where the request is coming from.
• Timing-Allow-Origin: Specifies which origins are allowed to access detailed timing information for a resource. For example, Timing-Allow-Origin: * enables all origins to view performance metrics like response time and network latency.

Optimization and Client Hints

These headers help browsers share device and network information with servers to optimize content delivery and performance. They are handy for responsive design and efficient resource loading.

• Accept-CH: Tells the browser which client hints the server wants in future requests. For example, Accept-CH: DPR, Viewport-Width helps tailor images for different devices.
• Save-Data: Indicates that the user prefers reduced data usage. For example, Save-Data: on helps the server send lower-resolution images or fewer scripts.
• DPR: Stands for Device Pixel Ratio and informs the server about screen density. For example, DPR: 2.0 means the device has a high-resolution display.
• Viewport-Width: Provides the layout viewport width in pixels. For example, Viewport-Width: 360 lets the server send content sized appropriately for a mobile screen.
• Width: Indicates the ideal width of the requested image. For example, Width: 720 helps the server choose or generate an image that fits.
• Device-Memory: Shares how much RAM is available on the device. For example, Device-Memory: 4 means the device has 4 GB of RAM.
• Early-Data: Signals if the request is sent before the TLS handshake is complete. For example, Early-Data: 1 helps avoid replay risks in HTTP/2 or 0-RTT.

Proxy and Connection Headers

These headers control how requests pass through proxies or manage connection settings between client and server. They are especially relevant in environments with multiple layers, such as load balancers or CDNs.

• Connection: Controls whether the network connection stays open. For example, Connection: keep-alive keeps the TCP connection open for reuse.
• Keep-Alive: Works with the Connection header to set how long the connection stays open. For example, Keep-Alive: timeout=5, max=100 defines a 5-second timeout and 100 max requests.
• Forwarded: Standardized way to share details of the original request through proxies. For example, Forwarded: for=192.0.2.43; proto=https tells the server who made the request and how.
• Via: Lists the proxies through which the request was passed. For example, Via: 1.1 proxy1.example.com helps in debugging proxy chains.
• X-Forwarded-For: Identifies the client’s originating IP address. For example, X-Forwarded-For: 203.0.113.1 shows the real IP behind a proxy.
• X-Forwarded-Host: Shares the original host requested by the client. For example, X-Forwarded-Host: www.example.com helps restore correct URLs behind a proxy.
• X-Forwarded-Proto: Tells whether the original request used HTTP or HTTPS. For example, X-Forwarded-Proto: https allows apps to redirect securely if needed.

Range and Conditional Headers

These headers help control partial content delivery or determine if content has changed. They’re essential for efficient data transfer, especially with large files or repeated requests.

• Range: Requests a specific part of a resource. For example, Range: bytes=0-499 asks for the first 500 bytes of a file.
• Accept-Ranges: Tells the client whether partial requests are supported. For example, Accept-Ranges: bytes means the server accepts range requests.
• Content-Range: Sent in the response to show which part of the resource is delivered. For example, Content-Range: bytes 0-499/1234 means 500 bytes out of a 1234-byte file.
• If-Range: Combines conditional and range requests. For example, If-Range: “abc123” ensures the partial response is only sent if the resource hasn’t changed.
• If-Match: Sends the request only if the resource matches the given ETag. For example, If-Match: “xyz789” prevents overwriting an updated file.
• If-None-Match: Tells the server to respond only if the ETag doesn’t match. For example, If-None-Match: “xyz789” helps avoid downloading unchanged content.
• If-Modified-Since: Requests the resource only if it has been updated after the given date. For example, If-Modified-Since: Tue, 11 Jun 2024 10:00:00 GMT.
• If-Unmodified-Since: This is the opposite of the above, and it processes the request only if the content hasn’t changed. For example, If-Unmodified-Since: Tue, 11 Jun 2024 10:00:00 GMT.

WebSocket and Streaming Headers

These headers support protocols like WebSocket or enable streamed content, which sends data in chunks rather than all at once. They are useful for real-time applications or large file transfers.

• Sec-WebSocket-Accept: Used during the WebSocket handshake to confirm the connection is valid. For example, Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= is the server’s response to a WebSocket upgrade request.
• Transfer-Encoding: Defines how the response body is formatted or chunked. For example, Transfer-Encoding: chunked sends data in segments without knowing the full size beforehand.
• TE: Indicates the types of transfer encodings the client supports. For example, TE: trailers tells the server the client can accept additional headers at the end of a chunked response.
• Trailer: Lists which headers will appear at the end of a chunked message. For example, Trailer: Expires tells the client to expect an Expires header after the body.

How to View and Test Headers in the Browser

You can inspect and test headers in your browser to debug issues, verify configuration, or confirm behavior in staging or production.

• View Headers with DevTools: In Chrome or Firefox, open DevTools (F12), go to the Network tab, and reload the page. Select any request to see the detailed request and response headers.
• Test Headers Without Code Changes: Use browser tools like Requestly to override or inject headers on live pages. This helps simulate different scenarios without touching the backend code.

How Can Requestly Help with HTTP Headers?

Requestly’s Modify HTTP Headers feature allows developers to control HTTP request and response headers during development or testing, without changing any backend code. It works directly in the browser and supports both simple and advanced use cases. Below are the key capabilities:

• Add, remove, or override headers: You can freely modify any header field in a request or response, such as adding Authorization, removing X-Frame-Options, or changing User-Agent.
• Bypass CORS restrictions: Insert or change CORS-related headers like Access-Control-Allow-Origin, Access-Control-Allow-Headers, and Access-Control-Allow-Methods to avoid browser-side CORS errors during local testing.
• Simulate authenticated sessions: Automatically add headers like Authorization: Bearer <token> to test protected APIs or simulate user sessions without logging in.
• Inject custom headers for feature testing: Use headers such as x-user-id or x-feature-flag to mock different users, states, or feature access conditions across pages.
• Remove security restrictions: Disable headers like Content-Security-Policy or X-Frame-Options to allow iframe embedding or to test custom scripts in restrictive environments.
• Test third-party behavior: Modify headers in outgoing requests to test how external APIs, CDNs, or other services respond under different conditions.

Talk to an Expert

Best Practices for Working with Headers

These best practices help prevent issues with performance, security, and browser compatibility.

• Avoid Unnecessary Headers: Don’t include headers that have no impact or are unused by your application. They increase request size and add noise.
• Protect Sensitive Information: Never expose tokens, API keys, or internal server info in headers unless strictly necessary and secure.
• Be Specific with CORS Rules: Avoid using wildcards like * for sensitive endpoints. Define allowed origins and methods clearly.
• Always Set Correct Content-Type: This helps the browser interpret responses correctly and prevents form submissions or JSON parsing issues.

Conclusion

HTTP headers shape how content is delivered, cached, secured, and personalized across the web. They also influence login states, access control, language preferences, and API behavior, making them critical for any modern web application.

With Requestly, you can modify headers directly in your browser to test different states, simulate user conditions, and resolve issues faster. It removes the need to change backend code and helps developers debug, validate, and collaborate more efficiently.

Try Requestly for Free