HTTP Headers Checker
Pull the live HTTP response headers for any URL and read them as a report: security coverage, cache, redirects and cookie flags.
This HTTP headers checker pulls the live response headers for any URL from our server side, then hands them back as a report you can paste straight into a ticket instead of curling and squinting. You get the status, the response time, redirect hints, and the headers that actually matter: the security policies handed to the browser, the caching and compression story, the content type, cookie flags, and how loudly your stack announces its build. It scores the security header coverage against a sensible baseline of five, flags a chatty Server or X-Powered-By line, and notes what to fix today versus what to test in staging first. It reads the exact URL you type and does not chase redirects, so a 301 shows up as a 301, and the redirect tab traces the path on its own. The raw values stay on screen the whole time.
Queries run through the PeopleAreGeek lookup service. We log nothing.
Live HTTP response audit
I got tired of curling a site and squinting at the headers, doing the mental tally of what's missing. So I built this. It fetches the response headers from our server side, then hands you a report you can paste straight into a ticket. Status. Response time. Redirect hints, the security headers, caching and compression, content type, cookie flags, and how loudly your stack is announcing itself. The raw values never get hidden either. They're right there.
One thing to know. This fires a server-side HEAD at the exact URL you hand it, and it won't chase redirects for you. URL bounces? The redirect tab quietly asks the redirect checker to trace the path on its own.
What an HTTP headers checker should tell you
An HTTP headers checker pulls the server's note to the browser, the lines scribbled before a single pixel renders. Is the status healthy? Is a redirect in play, did compression kick in, what content type actually came back, and which security policies got handed to the browser. I've audited pages that looked flawless on screen and still had wide-open policy underneath, caching that never once refreshed, a server header happily broadcasting its exact version. So yeah. The page being fine and the headers being fine are two very different things.
Built for the actual job, not for a pretty screenshot. The raw values stay on screen. But it also turns them into decisions you can act on: what's there, what isn't, what to fix today, and what you'd honestly better test in staging first before you go poking at a live WordPress box behind a CDN.
Headers worth reading first
- Status and Location get my first glance. Did I get a page back, or did I get bounced somewhere?
- Content-Type tells me what actually came back. HTML, JSON, an image, a download, or something I genuinely wasn't expecting.
- Cache-Control, ETag, Last-Modified and Vary are the whole caching story, start to finish.
- Content-Encoding tells me one thing only: did this particular response go out compressed.
- Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy and the frame headers are the ones that actually tighten the browser down.
Security headers need context
A missing header isn't a button you just slam on. Take HSTS. Turn it on before HTTPS is rock-solid across the host and every subdomain you serve, and you can lock yourself clean out of your own site. CSP is the one that's bitten me hardest, honestly. Ship a strict policy in a rush and you'll be explaining to someone why the contact form, the analytics, the ad slots, an embed, half of wp-admin all quietly stopped working. Framing control can live in CSP frame-ancestors, in X-Frame-Options, or both, if you still care about ancient clients. So read the report. Test it in staging if you've got one. And always, always retest through your CDN once it's live.
Headers, performance and SEO
Quick myth, dead and buried: Google won't rank you higher because your header table looks tidy. What it does clock is whether pages answer reliably, redirect the same way every single time, stay on HTTPS, hand back the content they're supposed to without throwing friction at users or crawlers. Clean headers are the floor under all that. They earn their keep alongside real content, sane internal links, a sitemap that actually covers things, pages that are genuinely indexable. Alongside, though. Not instead of.
Frequently asked questions
Why does the checker show a redirect instead of the final page headers?
Because it reads the exact URL you typed. Full stop. It doesn't follow the bounce. So if that URL is a 301 or 302, the redirect is what comes back, and that's the correct answer. Trace the path in the redirect tab. Then run the final destination through here too, because that's where the headers you actually care about are sitting.
Is a server header always a vulnerability?
No. I wouldn't lose a minute of sleep over a plain one. Half the web announces a generic server name and nothing bad ever comes of it. What I do trim is the chatty version. The second a header spells out your exact build, you've basically handed an attacker the list of CVEs to try first. Why make that part easy for them.
Does missing compression here mean the whole site is uncompressed?
Not necessarily. Compression bounces around depending on file type, which CDN node answered, the request method, even the sheer size of the response. Tiny payloads skip it on purpose half the time. So read this as one data point. Not the verdict. Then retest the exact path you're actually worried about.
Which security headers should every site send?
My baseline runs to five. Strict-Transport-Security, a Content-Security-Policy, X-Content-Type-Options set to nosniff, a Referrer-Policy, and framing locked down with either X-Frame-Options or CSP frame-ancestors. Nail those and the easy wins are mostly behind you.
What does the Cache-Control header do?
It's the instruction you hand browsers and CDNs about this one response. Can they store it? For how long, and when do they need to circle back and check it's still fresh. Get it wrong and people either stare at stale pages or hammer your origin for no good reason.
Why do server-side header checks differ from my browser?
Because a lot happens between the origin and your dev tools. A CDN edge, a reverse proxy, even your own browser cache, any of them can bolt on headers or quietly drop a few. This tool talks to the server directly. So what you see is what the origin really put on the wire. Not whatever limped through after the trip.