HTTP Header Checker

Why I Check HTTP Headers Before Everything Else

Here's something that might sound weird to non-developers: when I'm debugging a website issue, checking HTTP headers is literally the first thing I do. Before looking at code. Before checking the database. Before anything else.

Why? Because headers tell you what's actually happening between the browser and server. They're like reading the conversation instead of guessing what was said. And I can't tell you how many hours this habit has saved me over the years.

The Invisible Conversation

Every time you visit a website, your browser and the web server exchange messages you never see. Your browser says "Hey, I want this page." The server responds with the page content, but also sends back a bunch of metadata—HTTP headers—that tell the browser how to handle that content.

Should the browser cache this page? For how long? Is this connection secure? Is the server redirecting to a different URL? What type of content is this? All of this happens in headers, completely invisible to users.

When Headers Actually Matter (Real Examples)

Let me give you some specific situations where checking headers saved the day:

The Mysterious Redirect Loop

I was working on a site that randomly went into redirect loops. Users would get "too many redirects" errors, but only sometimes. The site worked fine for the development team.

Checking headers revealed the problem: the site was redirecting HTTP to HTTPS (good), but then HTTPS was redirecting back to HTTP (bad). This only happened on certain pages where a plugin was overriding the SSL settings. The headers showed the exact redirect chain: HTTP → HTTPS → HTTP → HTTPS... loop forever.

The "Broken" Form

Someone reported that a contact form wasn't working. They'd fill it out, submit, and nothing happened. No error message, no confirmation, just... nothing.

Header check showed the form submission was returning a 302 redirect followed by a 503 error. The redirect was going to a thank-you page that didn't exist (503 = service unavailable). The form was actually submitting fine—the emails were being sent—but the redirect target was broken. Without headers, we might have spent hours troubleshooting form processing code that was working perfectly.

The Security Audit Failure

A client failed a security audit because they were missing several security headers. Their developer said everything was configured correctly in the server config. Headers showed none of the security headers were actually being sent. Turned out their CDN was stripping custom headers. The server was sending them, the CDN was removing them, users never received them.

Understanding What You're Looking At

Let me break down the key headers and what they mean in plain English.

Status Codes: The First Thing To Check

The status code tells you whether the request worked:

200 OK — Everything worked. This is what you want to see.

301 Moved Permanently — The page has moved to a new URL forever. Browsers and search engines will update their records.

302 Found (Temporary Redirect) — The page is temporarily at a different URL. Browsers won't update bookmarks.

304 Not Modified — The page hasn't changed since last time. Use the cached version.

403 Forbidden — You don't have permission to access this. Server refuses to serve it.

404 Not Found — The page doesn't exist. Classic.

500 Internal Server Error — Something broke on the server. Check server logs.

502 Bad Gateway — A proxy or load balancer couldn't connect to the actual server.

503 Service Unavailable — Server is temporarily down (maintenance, overload, etc.).

Security Headers: Protecting Your Users

These headers tell browsers to enforce security policies. Missing them doesn't mean your site is broken—but it does mean you're missing protection layers.

Content-Security-Policy (CSP) — This is the big one. CSP tells browsers which scripts, styles, and resources are allowed to load. A good CSP prevents most XSS attacks by blocking unauthorized scripts. If an attacker injects malicious JavaScript into your page, CSP can stop it from executing.

A basic CSP might look like: default-src 'self' — only load resources from your own domain. More complex policies allow specific external resources while blocking everything else.

Strict-Transport-Security (HSTS) — Once a browser sees this header, it will refuse to connect to your site over plain HTTP for a specified period. Even if someone types http://yoursite.com, the browser automatically upgrades to HTTPS. This prevents man-in-the-middle attacks that try to downgrade secure connections.

X-Frame-Options — This prevents your site from being loaded inside an iframe on another site. Why does that matter? Clickjacking attacks. An attacker could overlay your login form with invisible elements, tricking users into clicking things they didn't intend to click.

X-Content-Type-Options — When set to "nosniff," this stops browsers from trying to guess the content type. Without it, a browser might interpret a file differently than intended, potentially executing malicious code.

Caching Headers: Performance and Freshness

Cache-Control — The main caching header. Common values:

• max-age=3600 — Cache for 1 hour (3600 seconds)
• no-cache — Don't use cached version without revalidating first
• no-store — Never cache this at all
• public — CDNs and proxies can cache this
• private — Only the user's browser should cache this

ETag — A unique identifier for a specific version of a resource. When the content changes, the ETag changes. Browsers can ask "Is this ETag still valid?" and get a quick yes/no without downloading the whole resource again.

Last-Modified — When the resource was last changed. Similar purpose to ETag but uses timestamps instead of hashes.

Server Information Headers

Server — Usually shows what web server software is running (Apache, nginx, etc.). Some security professionals recommend hiding this to make your server less fingerprintable, though others argue security through obscurity isn't real security.

X-Powered-By — Often reveals what backend technology is running (PHP, ASP.NET, etc.). Same debate as the Server header about whether to hide it.

Common Issues I Find With Headers

Missing HSTS on HTTPS Sites

You've got SSL, great! But without HSTS, browsers don't know they should always use HTTPS. The first visit could still be intercepted until the redirect happens.

Aggressive Caching Without Versioning

Setting max-age to a year is fine for static assets—if you're using versioned filenames (style.v123.css). Without versioning, users get stuck with old CSS/JS until the cache expires.

CDN Stripping Headers

Your server sends security headers, but they never reach users because the CDN strips them. Always verify headers from the user's perspective, not just from your server.

Mixed Content After SSL Migration

Headers show HTTPS, but Content-Security-Policy is missing or too permissive, allowing HTTP resources. Modern browsers block mixed content, breaking images and scripts.

How Response Time Affects User Experience

The response time shown in this tool measures how quickly the server responds to a HEAD request—just the headers, no content. A healthy site should respond in under 500ms for headers alone.

If you're seeing multi-second response times for just headers, something's wrong. Common causes:

• Server is overloaded or underpowered
• Database queries are blocking the initial response
• DNS resolution is slow
• Geographic distance (server is on another continent)
• Cold starts on serverless functions

How To Use This Tool Effectively

1. Enter any URL — You can skip the https:// part, we'll add it automatically
2. Click Check Headers — We send a HEAD request and capture all response headers
3. Review the summary — Status code, response time, header count, security score
4. Check security analysis — Green checkmarks = good, red X = missing header
5. Browse all headers — The dark box shows every header returned by the server

What If I See Unexpected Results?

Remember that our tool checks from our server, not from your location. Results might differ from what you see locally because:

• CDNs serve different content based on location
• A/B testing might show different headers to different users
• Some sites serve different content to known bots vs browsers

Questions I Get Asked All The Time

"My site works fine, why do I need security headers?"

Security headers don't make your site work—they protect your users. Without them, your site is more vulnerable to attacks like XSS, clickjacking, and man-in-the-middle. The site "works," but users are less protected.

"Will security headers break my site?"

They can, if configured wrong. CSP in particular can block legitimate resources if you don't whitelist them. Start with report-only mode to see what would be blocked without actually blocking it.

"Why do some big sites score low on security headers?"

Usually complexity. Large sites with many third-party integrations struggle to implement strict CSP. Or they've decided the risk is acceptable. That doesn't mean you should skip them on your site.

"What's a good response time?"

For just headers (HEAD request): under 200ms is excellent, under 500ms is good, under 1000ms is acceptable, over 1000ms needs investigation.

Final Thoughts

HTTP headers aren't glamorous. Nobody's going to compliment your X-Content-Type-Options configuration at a party. But they're fundamental to how the web works, and understanding them makes you significantly better at debugging, security, and performance optimization.

I built this tool because I needed it constantly and got tired of opening curl in the terminal. If you work with websites at all—development, SEO, security, whatever—this should be one of your go-to diagnostic tools.

Check your site. Check your competitor's sites. Check that weird site that loads slowly. Headers tell stories.