godz.online
Back to tools

TLDR reference

HTTP headers

A searchable reference for the request and response headers you actually meet, each with a one-line meaning and example. Type to search, or filter by purpose. Everything runs in your browser.

42 shown

How it works

A searchable reference for the HTTP headers you actually meet, each with a one-line meaning and a realistic example value. Headers are the metadata that travels alongside every request and response - they control caching, content negotiation, authentication, CORS, cookies, security policy, and more. Type to search by name or meaning, or use the chips to browse just the request headers, the caching headers, or the security headers.

Each card names the header, says whether it rides on the request, the response, or both, explains what it does in plain language, and shows a sample value so you know the shape to expect. It covers the everyday ones like Content-Type, Authorization, Cache-Control, and Set-Cookie alongside the security headers such as Strict-Transport-Security and Content-Security-Policy that are easy to forget. Everything is static and runs in your browser, so the lookup is instant and works offline once loaded.

Example. Searching "cache" lines up Cache-Control, ETag, and Last-Modified so you can see how the response advertises freshness and how the conditional request headers If-None-Match and If-Modified-Since ask "has this changed?" in return. Filtering by the Security chip groups Strict-Transport-Security, Content-Security-Policy, and X-Content-Type-Options together.

FAQ

What is the difference between a request header and a response header?

Request headers are sent by the client and describe the request or the client itself - Accept says which formats it can handle, Authorization carries credentials, User-Agent identifies the browser. Response headers are sent by the server and describe the response or the server - Content-Type states the format being returned, Set-Cookie stores state, Cache-Control tells the client how long it may reuse the body. Some headers, such as Content-Type and Content-Length, appear in both directions because they describe whichever body they accompany.

How do caching headers actually work together?

Cache-Control sets the policy: max-age says how many seconds a response stays fresh, no-cache forces revalidation, and private or public say who may store it. Once a cached copy goes stale, the validators take over: the client sends back the saved ETag in an If-None-Match header (or the saved date in If-Modified-Since), and if nothing changed the server replies 304 Not Modified with no body, saving the download. Together they let a browser reuse content safely without refetching it every time.

Which headers improve security?

A handful of response headers harden a site. Strict-Transport-Security forces HTTPS for future visits. Content-Security-Policy restricts where scripts, styles, and other resources may load from, which is the strongest defence against cross-site scripting. X-Content-Type-Options: nosniff stops the browser guessing a different content type. The CORS family, led by Access-Control-Allow-Origin, governs which other origins may read a response. Setting these is one of the cheapest ways to reduce a site attack surface.

Are custom headers still prefixed with X-?

Not any more. The old convention of prefixing non-standard headers with X- (as in X-Forwarded-For) was deprecated back in 2012, because a header that becomes popular then either keeps a confusing X- forever or breaks compatibility when the prefix is dropped. New custom headers should simply use a clear, descriptive name without the prefix. Plenty of X- headers survive for historical reasons, so this reference still lists the common ones you will encounter in the wild.