Base64 Decode and Encode
Decode Base64 into text and encode text back to Base64 instantly in your browser.
Share
The inputted text is too long to include in a share link.
HTTP Security Headers Checker
Check a website's HTTP security headers, redirect chain, and common browser protection settings.
How to use this HTTP security headers checker
Use this checker as a first pass for browser security headers on public pages, then confirm fixes in your hosting or application stack.
- Enter the public URL you want to inspect.
- Review the redirect chain to confirm the final page is the one you expected.
- Use the header checks to find missing browser protections.
- Copy the header names into your web server, CDN, framework, or hosting configuration.
HTTP Security Headers Checker features
- Follow redirects and show the final URL that was checked.
- Check HSTS, CSP, frame protection, MIME sniffing, referrer policy, permissions policy, and opener policy.
- Prioritize failed, warning, and passing checks so the most important fixes appear first.
- Explain what each header does, why it matters, and how to fix it.
- Display the raw final response headers for troubleshooting.
Why security headers matter
HTTP security headers tell browsers how to handle scripts, frames, MIME types, referrer data, HTTPS enforcement, and cross-origin windows. They do not replace secure application code, but they add browser-level guardrails around common web risks.
Common examples include Content-Security-Policy for limiting script and resource loading, Strict-Transport-Security for enforcing HTTPS after the first visit, X-Content-Type-Options for reducing MIME sniffing, and frame protections for clickjacking resistance. Referrer and permissions policies help limit what information or browser capabilities are exposed.
Headers can vary by route, subdomain, CDN rule, authentication state, or response type. Check important public pages separately, especially login, checkout, embedded content, file downloads, and app entry points.
How the checker works
The checker follows up to five redirects, evaluates the final response headers, and reports missing, report-only, or unexpected values without crawling the whole site.
The result is a configuration review, not a penetration test. A site can pass these checks and still have insecure code, vulnerable dependencies, weak authentication, leaked secrets, or authorization problems. Treat warnings as prompts for review rather than a complete security verdict.
Some headers need careful rollout. Content-Security-Policy is often safest to test in report-only mode first, while HSTS should be enabled only when HTTPS works reliably for the relevant host and subdomains.
The checks are informed by the OWASP Secure Headers Project. Content Security Policy behavior follows the W3C CSP specification, and HSTS behavior follows RFC 6797.
HTTP security headers FAQ
Which URL should I check?
Check the exact page visitors use, such as your homepage, login page, app dashboard, or checkout flow. Headers can vary by path and subdomain.
Does a passing result mean my site is secure?
No. Security headers are one layer. A site can have good headers and still have application, dependency, authentication, or authorization issues.
Why was my URL blocked?
Only public websites can be checked. Local, private-network, and reserved addresses are blocked, so use the public production or staging URL instead.
Why do different pages on the same site show different results?
Headers can be set by route, framework, reverse proxy, CDN, or file type. Check the exact page or subdomain you care about.
Should I copy a Content-Security-Policy from another site?
No. CSP must match the scripts, styles, images, frames, and connections your own site needs. Start strict, test carefully, and avoid allowing more sources than necessary.
Built and maintained by utilkit. Found an issue? Send corrections to contact@utilkit.com