Mixed Content Warnings: What They Are and How to Fix Them

Mixed content occurs when an HTTPS page loads resources — images, scripts, stylesheets, iframes — over HTTP. Modern browsers either block these resources or display a security warning. Even with a valid SSL certificate, mixed content can break your site's functionality, hurt SEO, and destroy user trust.

Why Mixed Content Is a Security Problem

When a browser loads an HTTPS page, the padlock icon signals that the connection is encrypted and the content has not been tampered with. Loading any resource over HTTP breaks this guarantee — an attacker performing a man-in-the-middle (MITM) attack can intercept and modify that HTTP resource even though the page itself is served over HTTPS.

In the worst case, a script loaded over HTTP could be modified to execute malicious JavaScript on your trusted HTTPS page — stealing session cookies, capturing form data, or redirecting users to phishing sites.

Active vs Passive Mixed Content

How to Find Mixed Content on Your Site

There are several ways to detect mixed content:

# Search HTML, JS, CSS for http:// URLs
grep -r "http://" ./public --include="*.html" --include="*.css" --include="*.js"

# For WordPress databases:
SELECT * FROM wp_posts WHERE post_content LIKE '%src="http://%';

How to Fix Mixed Content

Fix 1: Change http:// to https:// in your code

The direct fix. For resources hosted on servers that support HTTPS, simply change the protocol. For resources that do not support HTTPS, you must find an alternative host or self-host the resource.

<!-- Before (mixed content) -->
<script src="http://cdn.example.com/jquery.min.js"></script>
<img src="http://images.example.com/logo.png" />

<!-- After (fixed) -->
<script src="https://cdn.example.com/jquery.min.js"></script>
<img src="https://images.example.com/logo.png" />

Fix 2: Use protocol-relative URLs

Protocol-relative URLs (starting with //) automatically use the same protocol as the page. However, this is considered outdated — explicit https:// is preferred since all your pages should be HTTPS anyway.

Fix 3: Content-Security-Policy: upgrade-insecure-requests

This HTTP header tells browsers to automatically upgrade all HTTP requests to HTTPS before making them. It is a safety net, not a substitute for fixing your code:

Content-Security-Policy: upgrade-insecure-requests

# Nginx example:
add_header Content-Security-Policy "upgrade-insecure-requests";

# Apache example:
Header always set Content-Security-Policy "upgrade-insecure-requests"

Fix 4: WordPress-specific solutions

# Option 1: Plugin — "Really Simple SSL" handles most cases automatically

# Option 2: WP-CLI database search and replace
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables

# Option 3: wp-config.php
define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
  $_SERVER['HTTPS'] = 'on';
}

Preventing Mixed Content in Future Deployments