Base64 Decode and Encode
Decode Base64 values into UTF-8 text or encode text as standard Base64 in your browser, with clear input and copy controls.
Share
The inputted text is too long to include in a share link.
HTTP Security Headers Checker
Check a public website's redirect chain and HTTP security headers, including CSP, HSTS, frame controls, and referrer policy.
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.
Treat header findings as the start of a security review
Security headers tell a browser how to handle certain risks, but a good header score does not make an application secure. Authorization, session handling, input validation, dependency updates, server configuration, and application logic still matter. A missing header is a lead to investigate, while a present header must also have an effective value.
Check the final response and the redirect chain. An HTTP-to-HTTPS redirect should lead to the intended host, and sensitive intermediate responses should not expose data. HSTS is processed over secure connections and has deployment consequences for subdomains. RFC 6797 defines HSTS behavior; enable long durations and subdomain coverage only after confirming every affected host supports HTTPS.
Content Security Policy is most useful when it reflects the resources the page genuinely needs. A broad policy with unsafe script allowances can offer much less protection than its presence suggests. The W3C Content Security Policy specification describes directives and enforcement. Start in report-only mode when tightening a live site, review violations, then remove unnecessary sources.
Frame controls, content-type sniffing protection, referrer policy, and permissions policy address different browser behaviors. Do not add the strictest-looking value without checking product requirements such as legitimate embedding, downloads, cross-origin integrations, or device features. Test authenticated flows and third-party integrations after a change.
A remote check sees the response available from its network location. CDNs, geolocation, authentication, bot defenses, A/B tests, and cache state can produce a different response for a real user. Repeat the check from the browser's network panel and from deployment monitoring. Verify error pages and static assets where policies may differ from the main document.
Record the exact URL, time, final status, redirect chain, and response headers when reporting a finding. Avoid sending session cookies or private preview URLs to a third-party checker. Fixes belong in the server, reverse proxy, CDN, or application layer that actually emits the header, followed by tests that confirm the intended value remains present.
Header names are case-insensitive, and repeated fields may be combined differently by tools and proxies. Inspect the raw response when a value looks truncated or duplicated. A browser may also apply cached HSTS or CSP behavior that is not obvious from one request. Test in a clean profile only when you understand what cached state you are removing.
- Prioritize exploitable application issues and broken HTTPS before polishing a score.
- Assign each header to the layer that owns it and prevent multiple layers from emitting conflicting values.
- Deploy changes gradually, monitor CSP reports and application errors, and keep a documented rollback.
Final review checklist
- Capture the complete redirect chain and final response from the public URL, then compare it with an authenticated browser session and origin response.
- Review each header's actual directives and scope; presence alone does not prove that a policy is restrictive, compatible, or emitted consistently.
- Assign the fix to one owning layer so the application, proxy, and CDN do not produce duplicated or conflicting values.
- Roll out CSP, HSTS, and cross-origin changes with monitoring and a rollback, including error pages, subdomains, embeds, downloads, and third-party integrations.
- Prioritize exploitable application and transport flaws above a cosmetic score, and preserve evidence with URL, time, status, headers, and test conditions.
Built and maintained by utilkit. Updated . Found an issue? Send corrections to contact@utilkit.com
Related Utilities
HTTP Status Sandbox
Create temporary mock endpoints that return configurable HTTP status codes and response details for testing client error handling.
JSON Formatter
Beautify, minify, validate, and sort JSON in your browser while reviewing syntax errors, nested data, arrays, and object keys.