If your website is on HTTPS — which it should be in 2025 — mixed content is a maintenance issue you need to address promptly. Mixed content occurs when your secure HTTPS pages load resources over insecure HTTP. This creates security vulnerabilities, browser warnings, and signals poor site maintenance to search engines.

Types of Mixed Content

Passive mixed content includes images, video, and audio loaded over HTTP. These typically display security warnings in some browsers but usually still load. The padlock icon in the browser address bar may show an alert.

Active mixed content includes scripts, stylesheets, and iframes loaded over HTTP. Modern browsers block active mixed content entirely. If your CSS or JavaScript is served over HTTP on an HTTPS page, parts of your page will simply fail to load and users will see broken layouts or missing functionality.

Why Mixed Content Occurs

Mixed content usually accumulates when a site migrates from HTTP to HTTPS but hardcoded HTTP URLs remain in the database or templates. Third-party embeds such as videos, social widgets, and advertising networks may serve content over HTTP. Images uploaded before an HTTPS migration have HTTP URLs stored in the database. External resources like fonts loaded with HTTP URLs are another common source.

Finding Mixed Content

In Chrome DevTools, open the Console tab and load your page. Any mixed content warnings appear in red or yellow. The messages identify both the type of resource and the HTTP URL causing the issue.

For site-wide auditing, a site crawler or security audit tool identifies all mixed content across your site. Check every page type — mixed content often hides on product pages, old blog posts, or contact pages rather than on the homepage.

Fixing Mixed Content

The most common fix for WordPress sites is a database search-and-replace for your own domain: replace all instances of http://yourdomain.com with https://yourdomain.com. The Better Search Replace plugin handles this safely.

For template and theme files, search for any hardcoded HTTP URLs and update them to HTTPS. For third-party embeds, check whether the provider offers an HTTPS version — most do — and update the embed code accordingly.

The Content-Security-Policy upgrade-insecure-requests header instructs browsers to automatically upgrade HTTP sub-requests to HTTPS. This is a useful temporary measure while you fix underlying issues, but should not replace actually correcting the HTTP references in your code and database.

After fixing, recheck with Chrome DevTools Console and verify the padlock appears in the address bar on all key page types.