Security Tools

Mixed Content Detector

Check whether a website's security headers protect against mixed content.

Enter a domain to check whether its Content-Security-Policy header includes directives that protect against mixed content on HTTPS pages.

Checks response headers only - does not scan page content for mixed-content resources.

More Security Tools

View all 10

CORS Header Checker Security Headers Checker Permissions-Policy Checker HTTPS Redirect Checker Referrer-Policy Checker HSTS Checker X-Content-Type-Options Checker Content Security Policy (CSP) Checker

JustChecker monitors your security headers continuously and alerts you if any regress.

What Is Mixed Content?

Mixed content happens when an HTTPS page loads images, scripts or styles over plain HTTP. Browsers block or warn about it, which can break the page and remove the padlock. This tool checks whether a site sends the CSP directives that protect against it - upgrade-insecure-requests or block-all-mixed-content.

When to Use It

After moving a site to HTTPS.
When the padlock shows a warning on some pages.

How to Use It

Enter the domain.
Check whether a protective directive is present.

Understanding the Result

upgrade-insecure-requests makes the browser load HTTP resources over HTTPS automatically - a simple safety net while you fix old http:// links in content and templates.

Limitations

This checks the protective header, not every resource on the page. Use your browser's developer console to find the individual http:// resources.

Frequently Asked Questions

It's when an https page loads some of its resources (images, scripts, stylesheets) over plain, unencrypted http - even though the main page itself is secure, those specific insecure resources undermine the connection's overall protection.

Browsers distinguish "active" mixed content (scripts, stylesheets - things that could actually manipulate the page) which they block outright, from "passive" mixed content (images) which is typically just flagged with a warning since the risk is lower.

A common cause is a third-party embed, ad script, or old database entry that still references an http:// URL internally - a single overlooked hardcoded link is enough to trigger a mixed content warning.

Using protocol-relative URLs (starting with // instead of http:// or https://) or simply hardcoding https:// everywhere internally usually resolves it - a site-wide search-and-replace for lingering http:// references is a common cleanup step after a migration to https.

It can indirectly affect trust and engagement metrics (visitors seeing a security warning are more likely to leave), and search engines increasingly favor fully secure, warning-free pages when other ranking factors are comparable.

Yes - it commonly reappears when new content (a blog post with an old embedded image link, a new third-party widget) introduces a fresh http:// reference after the initial migration was otherwise complete.