HTTP Headers Inspector

What HTTP response headers tell you about a server

Every HTTP response includes a set of headers — metadata about the response, the server, caching policy, security posture, and more. Reading them tells you a lot about how a site is configured. This tool fetches a URL and shows every header verbatim, with a security audit highlighting which protective headers are present or missing.

The security headers that matter most

Modern browsers respect a set of response headers that materially improve a site's security posture. The most important:

• Strict-Transport-Security (HSTS) — tells browsers "always use HTTPS for this domain". Required for any site handling sensitive data. Standard value: max-age=31536000; includeSubDomains.
• Content-Security-Policy (CSP) — restricts which sources can load scripts, styles, frames. The single best defense against XSS. Even a basic default-src 'self' CSP shuts down most reflected-XSS attacks.
• X-Content-Type-Options: nosniff — prevents browsers from guessing content types. Stops a class of MIME-confusion attacks. Should always be present.
• X-Frame-Options: DENY (or frame-ancestors in CSP) — prevents your site from being loaded in an iframe on another domain. Stops clickjacking.
• Referrer-Policy: strict-origin-when-cross-origin — controls what referrer information is sent to other sites. Modern default is fine for most.
• Permissions-Policy — opt out of browser features (camera, microphone, geolocation, etc.) that your site doesn't use. Reduces attack surface.

Headers that reveal information attackers want

• Server — often reveals the exact server software and version (nginx/1.18.0, Apache/2.4.41 (Ubuntu)). Useful for fingerprinting and finding known vulnerabilities. Strip it in production.
• X-Powered-By — reveals the application framework (PHP/7.4.3, Express). Same fingerprinting concern. Set app.disable('x-powered-by') in Express.
• X-AspNet-Version, X-Generator — similar story for ASP.NET and various CMSes. Strip in production.

Hiding these doesn't make your server invulnerable — a determined attacker can fingerprint software through behavioral differences anyway. But it raises the bar against opportunistic scanners that match Server strings against CVE databases.

Caching headers, demystified

Caching behavior is controlled mainly by Cache-Control. The directives that matter:

• public — anyone can cache (including CDNs).
• private — only the end client can cache, not shared caches/CDNs.
• max-age=N — cache for N seconds.
• s-maxage=N — overrides max-age, but only for shared caches.
• no-cache — must revalidate before reuse (NOT "don't cache" — that's no-store).
• no-store — actually don't cache.
• immutable — the resource will never change at this URL. Use for fingerprinted asset URLs.
• stale-while-revalidate=N — serve stale for up to N seconds while fetching a fresh copy in background. Improves perceived performance.

A typical configuration for a static asset with a content-hash in its name: Cache-Control: public, max-age=31536000, immutable. For an HTML page: Cache-Control: public, max-age=0, must-revalidate (lets shared caches use it, but every request triggers a re-check).

Privacy & rate limit notes

This tool fetches the target URL from our server. We don't log URLs you inspect, but the target server will see our server's IP in its logs (not yours). For privacy-sensitive URLs you don't want to reveal to us, run curl -I <url> locally instead.

Rate-limited to 20 lookups per minute per IP. Internal/private addresses (localhost, 127.0.0.1, 10.0.0.0/8, 192.168.0.0/16) are blocked to prevent the tool from being used to probe internal infrastructure.