Why does a live fetch show fewer headers than curl -I on the same URL?

Browsers only expose a small "CORS-safelisted" set of response headers to page JavaScript on a cross-origin fetch - things like Cache-Control, Content-Type, and Expires - unless the server explicitly opts more in via Access-Control-Expose-Headers, which most sites don't configure. curl runs outside the browser's CORS sandbox entirely and sees every header the server actually sent, which is why it's the more complete source for anything beyond the safelisted set.

What does each category (Caching / Security / Content / Other) mean?

Caching covers headers that control how responses get stored and reused (Cache-Control, ETag, Expires, Last-Modified, Vary, Age, Pragma). Security covers headers that harden the browser's handling of the page (Strict-Transport-Security, CSP, X-Frame-Options, and similar). Content describes the response body itself (Content-Type, Content-Length, Content-Encoding). Everything else, including server-identifying and custom headers, falls under Other.

Should I be worried about headers that reveal my server software, like a Server or X-Powered-By header?

It's a minor information-disclosure concern, not a vulnerability by itself - it makes it marginally easier for an attacker to target known vulnerabilities in a specific server version, but removing it doesn't meaningfully improve security on its own ("security through obscurity"). Many teams strip it anyway since there's little upside to advertising it, but don't treat its absence or presence as a real security control.

Is it normal for the same header name to appear more than once?

Yes for some headers - Set-Cookie is explicitly allowed to repeat once per cookie being set, and Vary can list multiple values either as separate header lines or comma-separated in one line depending on the server. Most other headers appearing twice with different values is usually a misconfiguration (e.g. both a web server and an app framework setting the same header).

HTTP Header Checker - Inspect & Categorize Response Headers

Overview

Introduction

Response headers carry most of the operational information a browser or crawler uses about a page beyond its HTML: how long to cache it, whether it's safe to embed in a frame, what encoding the body uses, and dozens of other signals that never show up in the rendered page itself.

This tool gives a fast overview pass: fetch or paste a page's headers and see all of them at once, each tagged with a plain category, before drilling into a more specific checker for caching or security details.

What Is HTTP Header Checker?

A general-purpose HTTP response header viewer that categorizes every header it sees into one of four groups (Caching, Security, Content, Other) using a fixed lookup table of common header names.

It supports both a live fetch of a URL and a paste-in mode for headers copied from a browser's Network tab or a `curl -I` command, so it works even on pages that don't expose their full header set to a cross-origin browser fetch.

How HTTP Header Checker Works

A fetched or pasted header block is parsed into individual name/value pairs, then each header's lowercased name is checked against a fixed set of known Caching, Security, and Content header names; anything unmatched falls into Other.

The result is rendered as a full table plus a summary count per category, so a glance tells you roughly how many security-relevant headers are present before checking any of them individually.

When To Use HTTP Header Checker

As a first pass when auditing a page's server configuration, to see the full header set at a glance before running a more targeted checker.

When comparing what a server sends in production versus staging, since header differences (a missing cache header, an extra debug header) often reveal configuration drift.

Often used alongside Security Headers Checker, Cache Header Checker and Redirect Checker.

Features

Advantages

Gives a full-header overview in one view instead of requiring a separate lookup for each header's meaning.
Categorization makes it easy to spot at a glance that, say, zero Security-category headers are present, without reading every row individually.
Works identically whether headers came from a live fetch or a paste, since both paths feed the same parser.

Limitations

A live fetch is limited to CORS-safelisted response headers unless the target explicitly exposes more via Access-Control-Expose-Headers, so it will often show fewer headers than the server actually sent.
The category lookup table only covers common, well-known header names; custom or vendor-specific headers (e.g. X-Amz-*, X-Custom-*) are grouped under Other even when they're functionally about caching or security.

Examples

A typical static-asset response

Input

HTTP 200 OK
Cache-Control: public, max-age=31536000, immutable
Content-Type: application/javascript; charset=utf-8
Content-Encoding: br
ETag: "a1b2c3"

Output

4 headers found
Caching: 2, Content: 2
Cache-Control -> Caching
Content-Type -> Content
Content-Encoding -> Content
ETag -> Caching

No Security-category headers appear at all in this example, which is worth a second look for a document response but is normal for a fingerprinted, immutable static asset.

Best Practices & Notes

Best Practices

Run this on your production HTML document response, not just static assets, since document responses are where security headers matter most.
Treat a live-fetch result with a suspiciously short header list as a CORS-visibility limitation first, not necessarily proof the server is sending few headers - confirm with a paste from curl -I before drawing conclusions.

Developer Notes

The category lookup is a fixed Set-based table (see CACHING_HEADERS / SECURITY_HEADERS / CONTENT_HEADERS in the lib module) matched against the lowercased header name; it intentionally does not attempt to parse header values for categorization, only names, to keep the logic predictable.

HTTP Header Checker Use Cases

Getting a full inventory of what headers a page's server sends before deciding which specific checker (caching, security) to run next
Spotting an unexpected or leftover debug/internal header in a production response
Comparing header sets between two environments (staging vs production, before vs after a CDN change) to find configuration drift

Common Mistakes

Assuming a live-fetch header list is complete when it's actually just the CORS-safelisted subset, and concluding a header is "missing" when it's only hidden from the browser.
Only checking headers on the homepage and assuming every other page's server configuration matches, when caching or security headers are often set per-route or per-content-type.

Tips

Paste the output of `curl -sI https://example.com` for the most complete and reliable header list, since it bypasses browser CORS visibility limits entirely.

HTTP Header Checker