HTTP Header Checker
Security, Compression And Caching
This HTTP header checker reads the response of any page and grades it in one pass: the eight security headers, compression, caching and what the server gives away. Then it writes the lines that fix each gap, for Apache, Nginx or a headers file.
- FreePrice
- 23Checks
- IncludedFix
- NothingStored
HTTP Header Checker
Eight security headers, compression and caching, judged in one pass
- Score
- —
- Passing
- 0
- Warnings
- 0
- Failures
- 0
- First byte
- —
| Header | Value | Verdict | What it means |
|---|---|---|---|
| Paste an address above and the response lands here. | |||
The score is our own weighting of the rows above, not an industry grade. HTTPS, the policy and compression carry the most; anything marked as information carries none.
Ready-made lines for every header above that failed or warned. Pick your server, paste the lines, then run the check again.
Ready. Paste any public address and this server opens two connections to it.
What Response Headers Decide
Every page arrives with a few lines the visitor never sees. Those lines are the response headers.
They tell the browser how to treat the page: which scripts may run, whether it may sit in a frame, how long it may be kept, and whether it came compressed.
So two pages with identical content can be very different in speed and safety. The difference lives entirely in the headers.
This checker reads them from a live address, grades each one, and then hands you the configuration that would fix the weak ones.
The Eight Security Headers
Strict-Transport-Security keeps browsers on HTTPS. Content-Security-Policy decides which scripts may run, which is the main defence against injected code.
X-Content-Type-Options tells browsers to trust the declared file type. Frame protection, through X-Frame-Options or frame-ancestors, stops other sites wrapping yours in a frame to steal clicks.
Referrer-Policy limits what your address reveals to other sites. Permissions-Policy switches off the camera, microphone and location unless a page asks for them.
Finally, the two cross-origin policies keep other windows and other sites from reaching into the page. Together these eight close most of the doors an attacker tries first.
Why Compression Is Checked Separately
A server only compresses when the browser asks for it. Therefore this tool opens a second connection that offers gzip and brotli, and reports what comes back.
Compression usually cuts an HTML page by about seventy per cent. For that reason it is among the cheapest speed gains a site can make, and one of the most often missing.
The Vary header is checked with it, since a compressed page without Vary: Accept-Encoding can be served to the wrong browser by a shared cache.
Caching In Plain Words
Cache-Control says how long a copy may be reused. Without it, every browser and proxy invents its own rule, and they rarely agree.
ETag and Last-Modified let a returning browser ask whether its copy is still current. As a result, it can get a tiny "not modified" reply instead of the whole page again.
Details Your Server Reveals Without Asking
Server and X-Powered-By headers often name the exact software and version. That helps nobody visiting the page, although it saves an attacker a step.
Cookies are checked too. Each one should carry Secure, HttpOnly and SameSite, otherwise it can travel in the clear or be read by a script.
How The Fix Is Written
For every failing row that a configuration line can fix, the tool writes that line. You choose Apache, Nginx or a _headers file, and the block changes to match.
The Content-Security-Policy line is written as Report-Only on purpose. A generic policy switched straight on can block a site's own scripts, whereas report mode shows what would break first.
Some things are not header problems, such as a slow first byte. Those are listed but left out of the block, so nothing in it pretends to fix what it cannot.
About The Score
The score is our own weighting, not an industry standard. HTTPS, the content policy and compression count most, while rows marked as information count for nothing.
Working With the HTTP Header Checker, Start to Finish
One address in, a graded response and a ready fix out.
- 1
Paste the page address
Any public page works, and redirects are followed to the final answer.
- 2
Study the Denwix grade and the header list below it
The failures come first inside each group. Every row says what it found and why it matters.
- 3
Pick your server
Choose Apache, Nginx or a _headers file, and the fix block rewrites itself for that server.
- 4
Paste, reload, check again
Add the lines, reload the server, then run the check once more to watch the rows turn green.
What Sets This Header Checker Apart
Most header tools print the raw list and stop. This one explains it and fixes it.
Security, speed and caching together
Twenty-three checks in five groups, instead of three separate tools that each see part of the answer.
A ready-made fix for each header
Ready lines for Apache, Nginx or a _headers file, only for the rows that need them.
Compression really tested
A second connection asks for gzip and brotli, so the answer reflects what a real browser receives.
Safe defaults
The content policy arrives in report mode first, so trying the fix cannot break the site.
Raw headers one tap away
The unedited list sits in its own tab for anybody who wants to read every line.
Nothing kept
The address serves one check and then goes. This server writes no record of it.
Habits for Setting Response Headers
Eight habits that keep headers right after the first fix.
- Fix HTTPS before anything else. Every security header assumes an encrypted connection. On plain HTTP most of them do nothing.
- Roll out a content policy slowly. Start in report mode, read what it would block, then switch it on once the reports are quiet.
- Raise HSTS in steps. Start HSTS with a short max-age, make sure each subdomain works on HTTPS, then raise it to a year.
- Compress text, not images. HTML, CSS, JavaScript and SVG shrink a lot. JPEG and WebP are already compressed, so gzip gains nothing there.
- Say something about caching. Even no-store is better than silence, because silence lets every cache guess differently.
- Hide the version numbers. Turn off server tokens and X-Powered-By. They help attackers and nobody else.
- Flag every cookie. Secure, HttpOnly and SameSite on each one, including cookies set by plugins.
- Check again after each deploy. A new server, CDN or plugin can drop headers silently, so rerun the check whenever the stack changes.
Six Header Mistakes That Stay Hidden
None of these shows on the page, which is exactly why they last for years.
A policy with unsafe-inline
It looks like a content policy, although it lets injected script run. Rely on a nonce or a script hash in its place.
HSTS over plain HTTP
Browsers ignore it there. Browsers honour it only on a response served over HTTPS.
Headers only on the home page
Security headers set in one template miss every other page. Set them at the server instead.
Compression switched off by a proxy
A CDN or firewall in front of the site can undo what the origin set. Check the address visitors use.
Duplicate headers
Two different values for the same header, one from the app and one from the server, leave the browser to pick.
Feature-Policy instead of Permissions-Policy
The old name was retired years ago. Current browsers read only the new one.
HTTP Header Questions People Ask
What are HTTP headers?
They are short lines sent with every response, before the page itself. They instruct the browser on dealing with the response.
Which security headers belong on every website in 2026?
At the very least, send Content-Security-Policy, Strict-Transport-Security, Referrer-Policy, Permissions-Policy, X-Content-Type-Options and frame protection. The two cross-origin policies add further protection.
Will adding security headers change my rankings?
Not directly. However, HTTPS is a ranking signal, and compression and caching make pages faster, which does count.
Where do I paste the fix?
On Apache, into .htaccess with mod_headers enabled. For Nginx, inside the server { } section. On Netlify or Cloudflare Pages, into a _headers file at the site root.
Will the content policy break my site?
Not the one written here, because it is Report-Only. It blocks nothing and lists what an enforcing policy would stop.
Why does the Denwix grade differ from other header scanners?
Every tool weights the rows its own way. This one also counts compression and caching, which pure security scanners ignore.
I use WordPress. Which part of the server sets these headers?
Usually from the server or a plugin. The .htaccess lines work on most WordPress hosting that runs Apache.
Why is compression not measured?
The second connection that asks for gzip did not finish. The row is then left unjudged rather than guessed.
How is this different from the status code checker?
The status code checker shows what an address answers and where it redirects. This one grades the headers on that answer and writes the fix.
Is the address I check stored?
No. It serves one check and then goes, and nothing about it is logged.
Denwix Tools for Testing a Web Server
Headers are one layer of a response. These three check the others.
HTTP Status Code Checker
The status an address returns, and every hop on the way.
Open tool →SSL Checker
Certificate expiry, name cover and whether browsers trust it.
Open tool →Redirect Chain Checker
Every hop between the typed address and the final page.
Open tool →
Ready To Check Your Headers?
Paste an address, read the grade, and copy the fix for your server. The HTTP header checker is free, needs no account, and keeps no record of the check.