Every web response carries a set of headers — small key-value pairs telling browsers how to render, cache, secure, and trust the page.
This tool fetches a URL from our server and shows you exactly what came back. Useful for debugging your own site, auditing security headers, or inspecting which CDN and frameworks a competitor runs.
Pair with the SSL checker and uptime checker to get the full picture of a site's health in under a minute.
What HTTP headers are, in plain English
They're the envelope around every web response — they tell browsers how to handle the page, how long to cache it, and what security rules apply.
When you load a webpage, your browser sends a request, and the server sends back a response. The response has two parts: the body (the actual HTML, JSON, image, whatever you asked for) and the headers (instructions about the body). The body is what you see. The headers are what tell the browser how to treat what it sees.
A typical site sends back 15 to 40 headers per response. Some are basic plumbing — Content-Type, Content-Length. Some are security — Strict-Transport-Security, Content-Security-Policy. Some are operational — Cache-Control, ETag, Server, X-Powered-By. The tool above pulls all of them and surfaces them in order.
The security headers that actually matter
Four of them cover most of the risk surface, and most sites should have all four.
Strict-Transport-Security (HSTS) tells browsers "always use HTTPS for this domain, even if a user types http:// manually." Without it, attackers on the same Wi-Fi can hijack the first request before the redirect. The recommended value is max-age=31536000; includeSubDomains.
Content-Security-Policy (CSP) declares which scripts, styles, images, and frames the page is allowed to load. A tight CSP makes most cross-site scripting (XSS) attacks impossible. CSPs are hard to write correctly — the modern path is to use the script-src 'self' 'nonce-...' pattern and accept that you'll iterate.
X-Content-Type-Options: nosniff stops browsers from second-guessing the Content-Type header. Without it, a file declared as image/jpeg but actually containing JavaScript can sometimes get executed. The header is one line and there's no reason not to set it.
X-Frame-Options: DENY (or the modern Content-Security-Policy: frame-ancestors 'none') prevents your site from being embedded in an iframe by another site. That's the standard defence against clickjacking attacks.
Caching headers — getting them right
Wrong caching is the most common cause of "I shipped a fix but users still see the bug."
The two headers that matter are Cache-Control and ETag. Cache-Control tells caches (browser, CDN, proxy) how long they can keep the response without checking back. ETag is a fingerprint that lets caches ask "is this still the latest?" cheaply.
The right defaults: hashed assets (CSS, JS, images with content hashes in the URL) get Cache-Control: public, max-age=31536000, immutable. HTML and API responses get Cache-Control: no-cache (or short max-age plus ETag). Personal data gets Cache-Control: no-store, private. The wrong defaults look fine for weeks and then bite you the day you push an emergency fix that nobody can see.
What headers reveal about the stack
More than most operators realise — and not always intentionally.
The Server header often gives away the web server (nginx, Apache, Caddy, IIS), sometimes with the exact version. X-Powered-By gives away the framework (Express, PHP, ASP.NET, Rails). Set-Cookie with framework-specific names (PHPSESSID, JSESSIONID, _rails_session) gives away the runtime. X-Cache or CF-RAY headers reveal the CDN.
Some of this is fine to expose — Cloudflare is not a secret. Some of it is a small information leak — knowing the exact nginx version helps attackers when a vulnerability surfaces. Best practice is to strip X-Powered-By, hide specific version numbers, and let only essential operational headers through.
When to actually use this tool
Five common cases: site debugging, security audit, competitor research, redirect-chain check, and CDN verification.
If you ship a site and want to verify your security headers are present, this is the fastest way to see them. If you want to know what server and CDN a competitor uses, the response headers usually reveal both. If you've set up a redirect chain (HTTP → HTTPS → www → final) you can confirm each hop is set up correctly. And if you're auditing your own caching strategy, looking at Cache-Control / ETag side by side with the response time tells you whether the CDN is doing what you think it is.
Frequently asked questions
What are HTTP headers?
HTTP headers are small key-value pairs that travel alongside every web request and response. They tell the browser what kind of content is coming back, how to cache it, which security rules to apply, which compression was used, and many other things. The page itself is the body; the headers are the envelope.
Why would I want to view a site's HTTP headers?
Three common reasons: debugging your own site (is the caching header right, is the CSP doing what you expect, is the redirect chain clean), inspecting a competitor's tech stack (what server, which CDN, what frameworks), and security review (which security headers are set, are they correct, what's missing).
What is the Server header and is it safe to expose?
The Server header identifies the web server software running on the host — nginx, Apache, Cloudflare, Caddy, IIS. Modern security practice is to keep it generic. Old practice was to expose version numbers, which gives attackers a head start when a CVE drops.
What security headers should every site have?
The four big ones: Strict-Transport-Security (HSTS — forces HTTPS), Content-Security-Policy (CSP — controls what scripts and styles can load), X-Content-Type-Options: nosniff (stops browsers from sniffing the content type), and X-Frame-Options or frame-ancestors (prevents clickjacking).
What does Cache-Control actually do?
Cache-Control tells browsers and intermediate caches how long they can keep the response. Public, immutable, max-age=31536000 means 'cache for a year, never check again' — appropriate for fonts and hashed JS files. no-store means 'don't cache at all' — appropriate for personal data.
What is Content-Encoding?
It's the compression used on the response body. The common values are gzip (universal but old), br (Brotli — better compression, supported by all modern browsers), and zstd (newer, even better for big assets). If you see no Content-Encoding header at all, the site is sending uncompressed responses — a quick performance win.
Why does this tool sometimes show 403 even though the site works in my browser?
Some sites use bot-protection services that block server-to-server requests while allowing real browsers through. The 403 isn't an outage, just a 'come back with a real browser' message.
Do you log the URLs I check?
Standard web-server access logs are kept briefly for security and abuse detection, then rotated. We don't tie checks to your identity, don't sell or share the data, and don't track you across sessions.