Mixed content issues and fixes: The Complete 2026 Guide

Passive mixed content includes images, video, and audio files loaded over HTTP. Modern browsers display the content but show a "Not Secure" indicator in the address bar. This erodes user trust and increases bounce rate. Google's Chrome team moved all HTTP mixed content to "Not Secure" status starting in Chrome 94 Chrome Platform Status. Passive mixed content is less severe than active mixed content, but it still harms the user experience. Search engine crawlers see the insecure warnings and reduce trust signals.

Active mixed content includes scripts, stylesheets, iframes, fetch requests, and WebSocket connections loaded over HTTP. Browsers block active mixed content by default MDN Mixed Content. The page may break entirely. Interactive elements stop working. Tracking scripts fail to fire. Payment forms become unusable. Active mixed content triggers the most severe browser security warnings. Google considers active mixed content a high-priority fix for technical SEO. Unresolved active mixed content can lead to manual action from Google's webspam team.

Use browser developer tools to detect mixed content. The Console tab shows mixed content warnings in red. The Network tab filters show all resources served over HTTP. Crawling tools like Screaming Frog SEO Spider scan for mixed content across the entire site. Content Security Policy (CSP) reports detect mixed content at scale. Set the Content-Security-Policy header with report-uri or report-to directives to collect violation data CSP Specification. Google Search Console reports mixed content issues under the Security Issues section Google Search Console Security Issues.

Replace all http:// URLs with https:// in the source code. Start with the most critical resources: scripts and stylesheets. Update absolute URLs in the database, template files, and JavaScript files. Use protocol-relative URLs (starting with //) as an intermediate step, though these can cause issues in email and offline contexts. The permanent fix is to use https:// everywhere. Set up CSP upgrade-insecure-requests directive to automatically rewrite HTTP resources to HTTPS W3C Upgrade Insecure Requests. This directive tells the browser to upgrade all HTTP requests to HTTPS without changing the source code. CSP upgrade-insecure-requests works as a safety net but does not replace proper URL fixes.

Third-party scripts from CDNs, analytics providers, and ad networks often serve mixed content. Contact the provider and request HTTPS support. Many providers have deprecated HTTP endpoints. Replace third-party HTTP URLs with HTTPS versions. If a third-party resource does not support HTTPS, consider replacing the service entirely. Google recommends removing third-party resources that force mixed content on your site Google Web Security. The security of your site depends on every resource loaded on the page.

Set the Content-Security-Policy header to upgrade-insecure-requests. This header tells supporting browsers to automatically convert HTTP resource requests to HTTPS. It works across all modern browsers and covers both passive and active mixed content. The header alone does not fix the source URLs. It only changes how the browser handles them at render time. Combine CSP upgrade-insecure-requests with a full source code audit for complete coverage. Use a build-time check in your CI/CD pipeline to reject any commit that introduces a new HTTP resource URL.

The mixed content audit scans every page, every resource URL, and every third-party dependency for HTTP references. Note the gap between resources served correctly over HTTPS and those still loading over HTTP. Audit quarterly.