HTTP Headers Explained

HTTP headers are named metadata fields attached to requests and responses. They describe representation formats, caching, authentication, browser capabilities, security policy and many other aspects of a transaction. A header is not meaningful in isolation: direction, status, URL, browser behavior and its exact value all matter.

Request headers and response headers

A browser sends request headers such as Accept, Accept-Language and User-Agent. The server sends response headers such as Content-Type, Cache-Control and security policies. Some names can appear in both directions with related but distinct semantics.

The HTTP Headers Checker shows a privacy-conscious allowlist from your request to WhatWebSees. The Server Headers Checker contacts a public target and shows selected response fields. It intentionally excludes sensitive values such as Set-Cookie. Neither page is a raw packet capture.

Content type and representation

Content-Type tells the recipient the media type of a representation, for example text/html; charset=utf-8 or application/json. Correct typing affects parsing, rendering and security. X-Content-Type-Options: nosniff asks browsers not to reinterpret certain resources as a different type when that could create executable content.

Accept lets a client describe formats it can handle. Servers may perform content negotiation and use Vary to identify request fields that influenced the chosen representation. Caches need that information to avoid serving one language or encoding to a request expecting another.

Caching

Cache-Control carries directives for browsers and shared caches. max-age describes freshness lifetime; private limits reuse by shared caches; no-store asks caches not to store the response. no-cache is often misunderstood: it permits storage but requires validation before reuse.

Validators such as ETag and Last-Modified let a client ask whether stored content is still current. The server can reply 304 Not Modified without retransmitting the representation. Cache behavior also depends on request method, status code, intermediaries and browser policy, so one response header is only part of the story.

Compression

A client advertises supported content codings with Accept-Encoding, and the server identifies the selected coding with Content-Encoding. gzip and Brotli can reduce transfer size, but compression operates on the HTTP representation and is distinct from transport encryption. A diagnostic response time does not by itself measure whether compression improved a full page, because browsers also load scripts, styles, images and fonts.

Content Security Policy

Content-Security-Policy defines allowed sources and behaviors for content such as scripts, styles, images, frames and connections. A strong script policy can reduce the impact of injected markup, especially when it uses nonces or hashes rather than broad source allowances. CSP is defense in depth, not a substitute for output encoding and safe application design.

Policy correctness depends on the page. A header can be present but ineffective because it permits overly broad sources or unsafe behavior. Conversely, a deliberately simple resource may not need every directive. Content-Security-Policy-Report-Only allows observation without enforcement and should not be mistaken for an active blocking policy.

HSTS and HTTPS

Strict-Transport-Security tells supporting browsers to use HTTPS for a host for a specified period. includeSubDomains extends that rule, and preload expresses intent related to browser preload programs but does not itself add a domain to a list. Browsers accept HSTS only over a valid secure connection.

HSTS reduces exposure to future plaintext navigation after the browser knows the policy. It does not make an invalid TLS certificate acceptable and should be deployed carefully when subdomains may not all support HTTPS. See HTTPS and TLS Certificates Explained for the transport layer.

Referrer Policy

When following links or requesting subresources, browsers may send a Referer request header (the historical misspelling is part of HTTP). Referrer-Policy controls how much source URL information is included. Policies can suppress it, send only the origin across sites, or permit more detail in selected circumstances. Modern defaults tend to avoid sending full paths on cross-origin requests, but an explicit policy makes intent clearer.

Permissions and cross-origin isolation

Permissions-Policy controls access to selected browser features for the document and embedded frames. It is not a universal browser-permission replacement; feature support and syntax matter.

Cross-Origin-Opener-Policy (COOP) influences browsing-context isolation. Cross-Origin-Embedder-Policy (COEP) controls loading of cross-origin resources without suitable permission, and Cross-Origin-Resource-Policy (CORP) lets a resource restrict which sites may embed it. Some powerful capabilities depend on cross-origin isolation, but these headers can break legitimate integrations if enabled without testing.

Browser request signals

User-Agent traditionally exposes browser and platform tokens, many retained for compatibility. Client Hints provide structured fields, sometimes after server opt-in. Sec-Fetch-Site, Sec-Fetch-Mode and related Fetch Metadata headers describe request context and can support server-side isolation decisions. DNT and Sec-GPC communicate privacy preferences but have different histories and legal effects.

Headers can contribute to browser fingerprinting when combined with screen, language, time zone and graphics attributes. A single common value is rarely unique. Read Browser Fingerprinting Explained for the combination model.

Why a checklist is not a security grade

The Security Headers Checker reports “Present” or “Not observed” and shows values; it does not assign A–F grades. A CSP must fit the application, HSTS requires an HTTPS-ready domain, and cross-origin isolation has compatibility costs. Headers are one layer alongside secure code, authentication, authorization, dependency management and operational controls.

Responses can differ by path, method, authentication, geography, CDN edge and negotiation headers. A check of the homepage is useful evidence about that response, not a complete site audit.