HTTP-Header-Inspektor

What Are HTTP Headers?

HTTP headers are metadata fields transmitted between clients and servers as part of every HTTP request and response. They carry critical information about the message body, authentication credentials, caching behavior, content negotiation preferences, security policies, and connection management. Defined by RFC 9110 (HTTP Semantics), headers follow a simple Name: Value syntax where field names are case-insensitive and values can span multiple lines using obsolete line folding (though modern implementations avoid this). Understanding headers is fundamental to debugging API issues, diagnosing CORS failures, optimizing cache performance, and hardening web application security.

This tool parses raw HTTP headers — whether copied from browser DevTools, curl output, or server logs — and categorizes each header by its function: request context, response metadata, security policy, caching directive, or content negotiation signal. Each header is annotated with its purpose, common values, and security implications, making this tool invaluable for developers debugging network-level issues without memorizing the complete HTTP specification.

HTTP Header Categories and Taxonomy

RFC 9110 organizes HTTP header fields into several functional categories based on their role in the request-response lifecycle. Understanding this taxonomy helps you quickly identify which headers affect which aspects of communication:

• Request headers: Sent by the client to provide context about the request. Includes Host (mandatory in HTTP/1.1), User-Agent, Accept, Accept-Language, Accept-Encoding, Authorization, and Cookie. These headers tell the server what the client wants, what it can handle, and who it claims to be.
• Response headers: Sent by the server to describe the response. Includes Server, Set-Cookie, WWW-Authenticate, Location (for redirects), and Retry-After. These communicate server decisions, authentication challenges, and navigation instructions.
• Representation headers: Describe the body content of the message. Includes Content-Type, Content-Length, Content-Encoding, Content-Language, and Content-Location. These apply to both requests (POST/PUT bodies) and responses.
• Payload headers: Provide information about the payload data independent of the representation. Includes Content-Range and Transfer-Encoding (e.g., chunked). These are relevant for partial content delivery and streaming.

In addition to RFC 9110's core categories, widely adopted extension headers add functionality for security (Strict-Transport-Security), cross-origin control (Access-Control-Allow-Origin), caching (Cache-Control), and performance (Server-Timing). This tool recognizes and categorizes both standard and widely-deployed non-standard headers, providing contextual explanations for each.

Security Headers: Protecting Your Application

Security headers form a defense-in-depth layer that instructs browsers to enforce security policies on behalf of your application. Missing or misconfigured security headers are among the most common findings in web application security audits. The key security headers every production deployment should include are:

• Strict-Transport-Security (HSTS): Forces browsers to use HTTPS for all future requests to the domain. The max-age directive specifies how long (in seconds) the browser should remember this policy. Include includeSubDomains to cover all subdomains and preload for inclusion in browser HSTS preload lists.
• Content-Security-Policy (CSP): Declares which content sources are permitted, blocking XSS and injection attacks. A well-configured CSP is the strongest browser-enforced defense against cross-site scripting.
• X-Frame-Options: Prevents clickjacking by controlling whether your page can be embedded in frames. Values are DENY (never frameable), SAMEORIGIN (only same-origin frames), or ALLOW-FROM uri (deprecated, use CSP frame-ancestors instead).
• X-Content-Type-Options: Set to nosniff to prevent browsers from MIME-sniffing a response away from the declared Content-Type. This stops attacks where a malicious file is disguised with an innocent MIME type.
• Permissions-Policy: Controls which browser features (camera, microphone, geolocation, payment) your page and its embedded content can access. Successor to the deprecated Feature-Policy header.
• Referrer-Policy: Controls how much referrer information is included with requests. strict-origin-when-cross-origin is the recommended default — it sends the origin for cross-origin requests but strips the path and query string.

This tool highlights missing security headers and flags headers with weak configurations (such as HSTS with a low max-age or CSP with unsafe-inline), helping you identify gaps in your security posture directly from response headers.

CORS Headers: Debugging Cross-Origin Issues

Cross-Origin Resource Sharing (CORS) is the mechanism that allows browsers to relax the same-origin policy for specific cross-origin requests. CORS failures are among the most frustrating debugging scenarios for frontend developers because the browser blocks the response silently — your JavaScript code receives an opaque network error with no useful details. Understanding the CORS header exchange is the key to resolving these issues:

• Access-Control-Allow-Origin: Specifies which origins can access the response. Must exactly match the requesting origin or be * (wildcard, incompatible with credentials). A common mistake is returning a hardcoded origin when the application serves multiple frontends.
• Access-Control-Allow-Methods: Lists the HTTP methods permitted for cross-origin requests. Returned in preflight responses (OPTIONS requests) that browsers send before non-simple requests.
• Access-Control-Allow-Headers: Declares which request headers the server accepts from cross-origin requests. Custom headers like Authorization or X-Request-ID must be explicitly listed here.
• Access-Control-Allow-Credentials: When set to true, allows the browser to include cookies and HTTP authentication in cross-origin requests. Requires a specific origin (not wildcard) in Allow-Origin.
• Access-Control-Expose-Headers: By default, only CORS-safelisted response headers are accessible to JavaScript. This header exposes additional headers (like X-Total-Count or Link) to frontend code.
• Access-Control-Max-Age: Specifies how long (in seconds) the browser can cache preflight results, reducing the number of OPTIONS requests for repeated API calls.

When debugging a CORS failure, paste both the request and response headers into this tool. It will identify whether the issue is a missing Allow-Origin, an unlisted custom header in Allow-Headers, or a credentials/wildcard conflict.

Caching Headers: Performance and Freshness Control

HTTP caching headers determine whether browsers and intermediary proxies can store responses, how long cached content remains valid, and how revalidation works when content might be stale. Proper cache configuration can dramatically reduce server load and improve page load times:

• Cache-Control: The primary caching directive. Key values include public (cacheable by shared caches), private (only browser cache), no-cache (revalidate before use), no-store (never cache), max-age=N (fresh for N seconds), immutable (never revalidate — ideal for fingerprinted assets).
• ETag: A response validator — a unique identifier for a specific version of a resource. The browser sends it back as If-None-Match on subsequent requests, allowing the server to return 304 Not Modified if the content has not changed.
• Last-Modified / If-Modified-Since: Date-based cache validation. Less precise than ETags but simpler to implement for static file servers.
• Vary: Tells caches that the response depends on specific request headers. For example, Vary: Accept-Encoding ensures that gzipped and uncompressed versions are cached separately. Vary: Origin is critical for CORS responses to prevent cross-origin cache poisoning.
• Age: Indicates how long (in seconds) the response has been in a shared cache. Useful for diagnosing CDN behavior and cache freshness issues.

A common caching strategy for SPAs uses Cache-Control: no-cache for HTML documents (ensuring the browser always checks for updates) combined with Cache-Control: public, max-age=31536000, immutable for hashed static assets (CSS, JS, images) that never change once deployed.

Content Negotiation: Accept and Content-Type Mechanics

Content negotiation allows clients and servers to agree on the best representation of a resource. The client expresses preferences through Accept headers, and the server selects the most appropriate representation based on what it can produce:

• Accept: Declares which media types the client can process, with optional quality factors. For example, Accept: application/json, text/html;q=0.9, */*;q=0.1 prefers JSON but accepts HTML as a fallback.
• Accept-Encoding: Lists supported compression algorithms. Modern browsers send Accept-Encoding: gzip, deflate, br — where br (Brotli) typically achieves 15-20% better compression than gzip for text content.
• Accept-Language: Specifies preferred languages for the response. Servers use this for internationalization, returning localized content without requiring language in the URL path.
• Content-Type: Declares the media type of the message body. For API responses, this is typically application/json; charset=utf-8. For form submissions, the encoding is either application/x-www-form-urlencoded or multipart/form-data (for file uploads).

When an API returns 406 Not Acceptable, the server cannot produce a response matching the client's Accept header. Inspecting both the request's Accept and the response's Content-Type headers with this tool quickly reveals the negotiation mismatch. Quality factors (the q= parameter) range from 0 to 1, with 1 being the highest preference and 0 meaning explicitly unacceptable.

Code Examples

Parsing and categorizing HTTP headers in JavaScript

// Parse raw HTTP headers into a structured map
function parseHeaders(rawHeaders) {
  const headers = new Map();

  for (const line of rawHeaders.split('\n')) {
    const colonIndex = line.indexOf(':');
    if (colonIndex === -1) continue;

    const name = line.slice(0, colonIndex).trim().toLowerCase();
    const value = line.slice(colonIndex + 1).trim();
    headers.set(name, value);
  }

  return headers;
}

// Categorize a header by its function
function categorizeHeader(name) {
  const security = [
    'strict-transport-security', 'content-security-policy',
    'x-frame-options', 'x-content-type-options',
    'permissions-policy', 'referrer-policy'
  ];
  const cors = [
    'access-control-allow-origin', 'access-control-allow-methods',
    'access-control-allow-headers', 'access-control-allow-credentials',
    'access-control-expose-headers', 'access-control-max-age'
  ];
  const caching = ['cache-control', 'etag', 'last-modified', 'age', 'vary', 'expires'];

  if (security.includes(name)) return 'security';
  if (cors.includes(name)) return 'cors';
  if (caching.includes(name)) return 'caching';
  return 'general';
}

// Usage
const raw = `Content-Type: application/json
Cache-Control: no-cache
Strict-Transport-Security: max-age=31536000; includeSubDomains
Access-Control-Allow-Origin: https://app.example.com
X-Frame-Options: DENY`;

const headers = parseHeaders(raw);
for (const [name, value] of headers) {
  console.log(`[${categorizeHeader(name)}] ${name}: ${value}`);
}

Output:

[general] content-type: application/json
[caching] cache-control: no-cache
[security] strict-transport-security: max-age=31536000; includeSubDomains
[cors] access-control-allow-origin: https://app.example.com
[security] x-frame-options: DENY

Fetching and inspecting response headers with the Fetch API

// Inspect response headers from a real HTTP request
async function inspectHeaders(url) {
  const response = await fetch(url, { method: 'HEAD' });
  const report = { security: [], caching: [], cors: [] };

  // Check security headers
  const hsts = response.headers.get('strict-transport-security');
  if (hsts) report.security.push({ header: 'HSTS', value: hsts });
  else report.security.push({ header: 'HSTS', value: 'MISSING — add HSTS header' });

  const csp = response.headers.get('content-security-policy');
  if (csp) report.security.push({ header: 'CSP', value: csp.slice(0, 80) + '...' });
  else report.security.push({ header: 'CSP', value: 'MISSING — vulnerable to XSS' });

  // Check caching
  const cacheControl = response.headers.get('cache-control');
  report.caching.push({ header: 'Cache-Control', value: cacheControl || 'not set' });

  // Check CORS
  const allowOrigin = response.headers.get('access-control-allow-origin');
  if (allowOrigin) report.cors.push({ header: 'Allow-Origin', value: allowOrigin });

  return report;
}

// Example: inspect headers of your API
inspectHeaders('https://api.example.com/health')
  .then(report => console.log(JSON.stringify(report, null, 2)));

Standards & Specifications

• RFC 9110 (HTTP Semantics) — The definitive specification for HTTP header fields, content negotiation, status codes, and message semantics
• RFC 9111 (HTTP Caching) — Defines Cache-Control directives, freshness calculation, validation, and shared/private cache behavior
• OWASP Secure Headers Project — Security-focused guidance on HTTP response headers including recommended configurations and best practices