codynet

HTTP

HTTP Security Header Checker

Check HTTP response headers, redirect chains, and security headers (HSTS, CSP, COOP, and more) for any URL.

HTTP header inspector

Send a HEAD/GET request and follow redirects. Headers + status only — no body.

Private and reserved address ranges are blocked at the resolver layer.

Results

Sample Live example: the HTTP response headers for codynet.com. Inspect your own URL above to replace it.

1 hop(s)171 msfinal: 200
HEAD200 OK170 ms
https://codynet.com/
HeaderValue
cache-controls-maxage=31536000
content-length38653
content-typetext/html; charset=utf-8
dateTue, 07 Jul 2026 00:37:07 GMT
etag"vh4616bn1zts3"
varyrsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding
x-nextjs-cacheHIT
x-nextjs-prerender1, 1
x-nextjs-stale-time300

Practical guide

How to inspect HTTP headers

Use this page to see the status, redirect path, and response headers a server sends before a browser renders the page.

What this tool checks

The HTTP header inspector requests a URL and reports the final status code, the full redirect chain, and the response headers the server sends before a browser renders the page. Headers reveal caching rules, content type, compression, cookies, CDN behavior, and the browser security policies that matter most for site hygiene — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and the Cross-Origin isolation headers.

When to use it

Use it after deploying a site, changing redirect rules, moving behind a CDN, or tightening browser security headers. It is especially helpful when a page works in one browser but fails in another, when SEO tools report redirect, canonical, or mixed-content warnings, or when you need to confirm an HSTS or CSP change actually reached production rather than being cached at an old value.

How to read the result

Start with the status code. A 200 means the final URL returned content, 3xx responses show redirects, 4xx responses usually indicate a client or permission problem, and 5xx responses usually indicate a server-side failure. Then walk the redirect chain to confirm the final URL is intentional, and check that the security headers appear on that final response — not just the first hop. Headers like HSTS only take effect over HTTPS.

Common security headers and a sensible baseline

These are the response headers most worth checking. "Baseline" is a safe starting point, not a mandate — tune each to your application before enforcing it.

HeaderWhat it controlsSensible baseline
Strict-Transport-SecurityForces browsers to reuse HTTPSmax-age=31536000; includeSubDomains (once every subdomain is HTTPS)
Content-Security-PolicyRestricts where scripts, styles, and frames load fromStart in Report-Only, then enforce default-src 'self'
X-Frame-OptionsClickjacking / framing protectionDENY or SAMEORIGIN (or frame-ancestors in CSP)
X-Content-Type-OptionsStops MIME-type sniffingnosniff
Referrer-PolicyControls referrer leakage to other sitesstrict-origin-when-cross-origin
Permissions-PolicyGates powerful browser features (camera, geolocation, etc.)Disable features you do not use
Cross-Origin-Opener-PolicyIsolates your window from cross-origin openerssame-origin for isolated apps

Common findings and what they mean

Missing HSTS means browsers can be downgraded to HTTP on the first request — add it once HTTPS is solid. No CSP removes a major defense against injected scripts; a CSP that includes unsafe-inline or * is weak and worth tightening. Missing X-Frame-Options / frame-ancestors leaves the page open to clickjacking. A mixed redirect chain (http → https → www → apex) wastes round trips and can drop headers along the way. The most common real-world gap is security headers present on the homepage but missing on asset, API, or error routes — always test more than the front page.

Example HTTP header check

Example input
https://example.com
Example result
status: 200
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000
cache-control: max-age=604800

Security and caching headers are only useful when they are present on the final response users actually receive.

Related tools

TLS Certificate Inspector

Check the certificate behind the HTTPS endpoint and confirm trust status.

Open tool

DNS Lookup

Verify that a hostname resolves to the expected site or CDN target.

Open tool

Domain Whois / RDAP

Check registration data when ownership or domain status is part of the issue.

Open tool

Related guides

TLS Certificate Expiration And Troubleshooting

How TLS certificates fail and how to inspect what's actually served.

Read guide

What Is A CAA Record?

CAA records gate which CAs can issue certs for your domain — a useful complement to HTTP security headers.

Read guide

FAQ

What HTTP security headers should every site have?
A reasonable baseline for most HTTPS sites is Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, and clickjacking protection via X-Frame-Options or frame-ancestors in CSP. Permissions-Policy is a useful addition to disable browser features you do not use. Not every header applies to every site, so treat the list as a starting point rather than a strict requirement.
Is a missing Content-Security-Policy always a vulnerability?
No. A missing CSP is not itself an exploit, but it removes a strong layer of defense against cross-site scripting and content injection. A well-scoped CSP limits where scripts, styles, and frames can load from, so a single injected tag is far less likely to execute. It is best added carefully — start in Content-Security-Policy-Report-Only, watch for violations, then enforce.
What is HSTS and should I enable preload?
Strict-Transport-Security tells browsers to always use HTTPS for your domain for a set period, which prevents downgrade and cookie-stripping attacks. Preload goes further by hard-coding your domain into browsers so even the first visit is HTTPS-only. Only enable includeSubDomains and preload once you are certain every subdomain can serve HTTPS, because preload is slow and difficult to reverse.
Why do the headers change after a redirect?
The first response in a redirect chain (for example http:// or a bare domain) often carries only a Location header, while the security headers live on the final HTTPS response. Always confirm that headers like HSTS and CSP are present on the final URL users actually land on, not just the first hop.
Why does this tool show different headers than my browser?
Servers and CDNs can vary responses by request method, user agent, region, protocol version, or cache state. A header present for a logged-in browser session may be absent for a plain request, and edge caches can serve different responses by location. If results differ, test the exact final URL and compare with the equivalent curl -I command.
Does hiding the Server header make my site more secure?
Only marginally. Removing or obfuscating the Server and X-Powered-By headers is mild security-through-obscurity — it slows casual fingerprinting but does not fix any underlying issue. Spend effort on real controls (HSTS, CSP, patching, least-privilege) before worrying about banner hiding.
Can I check headers for a specific path, not just the homepage?
Yes. Enter the full URL including the path, such as https://example.com/app or an API route. This matters because security headers are often set on the homepage but missing on asset, API, or error routes, which is a common real-world gap.

Last reviewed: 2026-06-22.