HTTP Header Checker

Inspect HTTP response headers, security headers, redirect chain, and caching for any URL

Try:

Frequently Asked Questions

HTTP headers are key-value pairs sent between a client (browser) and server with every HTTP request and response. Response headers tell the browser how to handle the content — what type it is, whether it should be cached, if the page is secure, what scripts are allowed, and more. They are invisible to the user but critical for security, performance, and compatibility.
HSTS (HTTP Strict Transport Security) is a security header that tells browsers to always connect to the site over HTTPS — never HTTP. Once a browser sees this header, it will refuse plain HTTP connections to that domain for the specified duration (max-age). This prevents protocol downgrade attacks and cookie hijacking.
Content-Security-Policy is a powerful security header that controls which sources the browser is allowed to load scripts, styles, images, and other resources from. A properly configured CSP dramatically reduces the risk of XSS attacks. For example, default-src 'self' allows resources only from the same origin.
X-Frame-Options prevents a page from being embedded inside an <iframe> on another site, protecting against clickjacking attacks. Common values: DENY (never allow framing) and SAMEORIGIN (allow only from same origin). It has been largely superseded by the CSP frame-ancestors directive.
Cache-Control directives tell browsers and intermediate caches how to cache the response. max-age=3600 caches for 1 hour. no-cache means the browser must revalidate. no-store means never cache. public allows CDNs to cache; private means only the browser may cache.
HTTP redirects are responses with status codes 3xx that tell the client to fetch a different URL. Common ones: 301 (Moved Permanently), 302 (Found — temporary), 307 (Temporary Redirect — method preserved), 308 (Permanent Redirect — method preserved). This tool shows the full redirect chain from original URL to final destination.
The four most critical: Strict-Transport-Security — forces HTTPS; Content-Security-Policy — restricts resources, blocking XSS; X-Frame-Options — prevents clickjacking; X-Content-Type-Options: nosniff — stops MIME-sniffing. Adding all four significantly raises the security posture of any web application.
In Apache, use the Header directive (requires mod_headers): Header always set X-Content-Type-Options "nosniff". In Nginx, use add_header: add_header X-Frame-Options "SAMEORIGIN" always;. The always keyword ensures the header is sent on error responses too. In PHP: header('X-Content-Type-Options: nosniff');
Without a correct Content-Type, browsers perform MIME-sniffing — inspecting bytes to guess the type. An attacker can exploit this by uploading a file that looks like an image but contains HTML/JavaScript. Setting X-Content-Type-Options: nosniff disables MIME-sniffing, forcing the browser to trust only the declared Content-Type.

About This HTTP Header Checker

This free HTTP Header Checker fetches the HTTP response headers for any public URL. It checks for important security headers, shows the full redirect chain, and highlights caching configuration. Results include a security score based on the presence of recommended headers.

Key Security Headers

HeaderProtects Against
HSTSProtocol downgrade, MITM
CSPXSS, data injection
X-Frame-OptionsClickjacking
X-Content-Type-OptionsMIME sniffing
Referrer-PolicyReferrer leakage
Permissions-PolicyFeature abuse

Related Internet Tools

SSL Checker DNS Lookup WHOIS Lookup Port Scanner

Related Articles

In-depth guides and technical articles.

View all →
The Vary Header: Why Your Cache Serves the Wrong Content
Internet Sep 17, 2026
The Vary Header: Why Your Cache Serves the Wrong Content
The Vary header decides what counts as the same request to a cache. Missing it serves wrong content; overusing it destroys your hit rate. Here's how to get it right.
HSTS Doesn't Protect the First Connection — Why the Preload List Exists and How to Use It Safely
Internet Jul 9, 2026
HSTS Doesn't Protect the First Connection — Why the Preload List Exists and How to Use It Safely
HSTS tells browsers to use HTTPS only — but the first-ever connection to a site happens before HSTS takes effect, leaving a downgrade attack window. The HSTS preload list eliminates this by baking HTTPS-only policy directly into browsers before any connection. Here's why includeSubDomains is a commitment to all subdomains, how max-age=0 removes HSTS, and how HSTS silently fixes mixed content warnings for already-HSTS domains.
HTTP/2 and HTTP/3 Changed the Transport, Not the Headers — Here's What That Means in Practice
Internet Jun 19, 2026
HTTP/2 and HTTP/3 Changed the Transport, Not the Headers — Here's What That Means in Practice
HTTP/2 and HTTP/3 changed the transport layer — binary framing, header compression, multiplexing, QUIC — but the headers you see in a response inspector are mostly the same HTTP/1.1 headers. Here's what HTTP/2's HPACK compression and multiplexing actually do, what the :method/:path/:status pseudo-headers mean, how to identify which HTTP version served a response, and what the Alt-Svc h3 header signals about HTTP/3 availability.
Cache-Control Demystified: Why "no-cache" Doesn't Mean "Don't Cache," and Other Misread Directives
Internet Jun 19, 2026
Cache-Control Demystified: Why "no-cache" Doesn't Mean "Don't Cache," and Other Misread Directives
"Cache-Control: no-cache" doesn't mean "don't cache this" — it means "cache it, but check with the server before using the cached copy, every time." This single misconception is responsible for much "why is this still cached" confusion. Here's the real no-cache vs no-store distinction, why private vs public matters for shared CDN caches, what must-revalidate does when the server is unreachable, and why Vary headers matter for content that differs by language or compression.
CORS Explained: Why It's a Server-Side Fix for a Browser-Side Error, and How to Debug It
Internet Jun 16, 2026
CORS Explained: Why It's a Server-Side Fix for a Browser-Side Error, and How to Debug It
A CORS error appears in the browser console as if it's a client-side problem — but it's actually caused by missing response headers from the server, which is why "it works in curl/Postman but fails in the browser" is the classic CORS symptom. Here's same-origin policy, the key CORS headers, simple vs preflighted requests, and a systematic debugging approach.