Mixed Content Checker
Find insecure HTTP resources loading on your HTTPS pages. Check images, scripts, CSS, iframes, forms, and other elements for mixed content that breaks the padlock and triggers browser security warnings.
Check for Mixed Content
About the Mixed Content Checker
This tool fetches any HTTPS webpage and performs a comprehensive scan for HTTP resources that cause mixed content warnings. It checks all resource types:
Scans img src, srcset, data-src (lazy-loaded), picture source elements for insecure URLs.
Detects JavaScript files loaded over HTTP that browsers will block completely.
Checks link rel="stylesheet/preload", inline style url() references for HTTP URLs.
Why Mixed Content Matters for Your Website
Mixed content is one of the most common security issues on HTTPS websites. When you migrate from HTTP to HTTPS (which Google now treats as a ranking signal), some resources are often left behind as HTTP URLs. This creates a false sense of security — your page loads over HTTPS but pulls in resources over unencrypted connections.
The impact is significant:
- Broken pages:Active mixed content (scripts, CSS, iframes) is blocked by modern browsers, breaking page functionality silently. Users see a broken page without understanding why.
- Lost trust:The "Not Secure" warning in Chrome's address bar erodes visitor confidence. For e-commerce and login pages, this is devastating for conversion rates.
- Security vulnerabilities:HTTP resources can be intercepted and modified in transit (man-in-the-middle attacks). A script loaded over HTTP can be replaced with malicious code.
- SEO impact:While mixed content isn't a direct ranking penalty, the resulting poor user experience (bounce rate, broken functionality) indirectly affects search performance.
Best Practices for Fixing Mixed Content
- Find all HTTP resources — Use this tool to scan every page on your site. Pay special attention to templates, headers, footers, and shared components.
- Change HTTP to HTTPS — For most resources, simply replacing
http://withhttps://in the URL works. Test after changing. - Use protocol-relative URLs — Use
//example.com/file.jsinstead ofhttp://example.com/file.js. The browser automatically uses the page's protocol. - Implement CSP upgrade-insecure-requests — Add the HTTP header
Content-Security-Policy: upgrade-insecure-requestsas a safety net that automatically upgrades all HTTP requests to HTTPS. - Use CSP report-uri — Set up a CSP report-uri to monitor mixed content violations in production so you catch new issues as they appear.
- Host resources yourself — If a third-party resource isn't available over HTTPS, download and host it on your own server with HTTPS.
Frequently Asked Questions
Reviewed Jun 2026 · Sources and limitations
Review details: 2026-06-10 · Marc LaClear · v1.0
Reference sources:
- Google Search Central documentation
- Google Search Central crawling and indexing docs
- Google structured data guidelines
- Schema.org vocabulary
- MDN Web Docs for HTTP and HTML references
Known limits:
- Checks are based on publicly fetchable HTML, response headers, and browser-side input. They do not use private Google Search Console, analytics, or ranking data.
- Scores and warnings are diagnostic aids, not guarantees of ranking improvement or Google indexation.
- Pages blocked by robots.txt, login walls, bot protection, heavy JavaScript, or network timeouts may return incomplete results.
- Validate critical fixes with official Google tools such as Search Console, Rich Results Test, Lighthouse, and your own crawl data.