Check an HTTPS page for mixed content
Mixed content is when a page served over HTTPS still pulls in scripts, images, or styles over plain http://. Those requests are unencrypted, and browsers either block them outright or drop the padlock, so the page ends up both less secure and looking broken.
What it costs
On CheckWeb this is a weight-1 check on the Security axis, lighter than the gates around it, because a single insecure image is a smaller risk than a broken certificate. Its real cost is visible to every visitor: modern browsers block mixed active content like scripts, and downgrade the padlock, so the page loses protection and looks insecure at the same time.
How it looks in the report
Under the Security axis, "Mixed content (HTTP on HTTPS)". A clean page shows PASS with "No insecure (http://) subresources". A fail lists the insecure resources it found.
Mixed content (HTTP on HTTPS)
No insecure (http://) subresources
Present vs clean
Present
A page loads http:// assets. Active ones (scripts, iframes) get blocked by the browser; passive ones (images) drop the padlock.
Clean
Every subresource loads over https:// or a protocol-relative path.
How to fix it
- Change http:// asset URLs to https:// (or protocol-relative //) wherever the page controls them.
- For third-party assets, confirm the provider serves HTTPS, then update the URL.
- During a migration, a Content-Security-Policy with `upgrade-insecure-requests` can auto-upgrade requests while URLs are cleaned up (CSP guide).
- Verify: re-scan.
Check a page for mixed content
Paste a URL to see whether an HTTPS page loads any insecure http:// resources, and which ones. Fix, re-scan, confirm.
Check my website