API Header Inspector

How API Header Inspector Works

What are HTTP Headers?

HTTP headers are key-value metadata sent alongside every request and response, separate from the actual body content. They tell the other side of the connection how to interpret the message: what format the body is in, how long it can be cached, who's asking, what credentials they're presenting, and dozens of other operational details. A single request or response typically carries a dozen or more headers, most of them set automatically by the browser or server without any application code ever touching them directly.

Request Headers

Sent by the client to describe the request and what it can accept back: Accept and its variants for content negotiation, Authorization for credentials, User-Agent identifying the client, and conditional headers like If-None-Match for cache revalidation.

Response Headers

Sent by the server to describe what it's returning: Content-Type and Content-Encoding describing the body, Set-Cookie establishing client-side state, Location for redirects, and a range of CORS and security headers controlling how browsers are allowed to use the response.

General Headers

Apply to the message itself rather than specifically to a request or a response — Cache-Control, Connection, Date, and Transfer-Encoding are all about how the HTTP message is transmitted and cached, not what it contains.

Authentication Headers

Authorization carries the client's credentials (a Bearer token, API key, or Basic auth string); WWW-Authenticate is the server's response telling the client what authentication scheme it expects. Together they drive most API authentication flows.

CORS Headers

Cross-Origin Resource Sharing headers — Access-Control-Allow-Origin, -Allow-Headers, -Allow-Methods, and -Allow-Credentials — let a server explicitly permit browser JavaScript running on a different origin to read its responses. Misconfiguring these (especially combining a wildcard origin with credentialed requests) is one of the most common real-world web security mistakes.

Cache Headers

Cache-Control, ETag, Expires, and the conditional-request headers (If-Modified-Since, If-None-Match) work together to let clients and intermediate caches avoid re-downloading unchanged content, while still detecting when a resource actually has changed.

Security Headers

Strict-Transport-Security forces HTTPS-only connections, Set-Cookie's HttpOnly/Secure/SameSite flags protect session cookies, and careful Content-Disposition usage prevents user-uploaded content from being rendered as active content in the browser. Getting these right is foundational, unglamorous web security work.

Common Mistakes

• Reflecting Origin into Access-Control-Allow-Origin unconditionally. This effectively disables CORS protection — always validate against an explicit allow-list.
• Sending Authorization or Set-Cookie without HTTPS. Both should be treated as sensitive credentials, exposed to network eavesdroppers on plain HTTP.
• Setting both Content-Length and Transfer-Encoding: chunked. This conflicting combination is a well-known building block of HTTP request smuggling attacks.
• Trusting client-supplied headers (Host, User-Agent, X-Forwarded-For) for security decisions. Anything the client sends is, by definition, client-controlled and can be forged.

Related Tools

Working with HTTP headers often overlaps with other developer utility tasks: look up what a response status code means with the HTTP Status Code Reference, decode the Bearer token an Authorization header carries with the JWT Decoder, validate a header value's shape with the Regex Tester, fingerprint a response body with the Hash Generator, or explain a scheduled job that calls this API with the Cron Expression Parser.