You purchased or configured a valid SSL certificate. You set up 301 redirects from HTTP to HTTPS. You open your website in Google Chrome, expecting the clean security padlock icon.
Instead, the padlock is missing, replaced with an informational warning icon or a message stating:
"Your connection to this site is not fully secure."
This is known as a Mixed Content Warning. It occurs when the initial HTML document loads securely over HTTPS, but elements within the page (such as images, video files, audio streams, stylesheets, or JavaScript files) are loaded over insecure plain HTTP (http://).
In this technical guide, we examine the differences between active and passive mixed content, show you how to locate the offending asset in seconds using Chrome DevTools, and explain automated techniques to upgrade insecure requests across your entire site.
1. Passive Mixed Content vs. Active Mixed Content
Modern browsers categorize mixed content into two severity levels, each handled differently:
A. Passive Mixed Content (Mixed Display Content)
- Asset Types: Images (
<img>), videos (<video>), and audio (<audio>). - Browser Behavior: The browser usually still downloads and displays the image, but it revokes the secure padlock icon in the address bar to warn the user that the page is not completely secure.
- The Danger: An attacker on the local network could intercept and replace the insecure image with an offensive or fraudulent graphic without modifying the encrypted HTML.
B. Active Mixed Content (Mixed Script Content) - Extremely Dangerous
- Asset Types: JavaScript (
<script>), CSS stylesheets (<link rel="stylesheet">), fonts, iframes (<iframe>), andfetch()/XMLHttpRequestAPI calls. - Browser Behavior: Modern browsers block active mixed content completely by default. The script or stylesheet will fail to execute, causing console errors like
Blocked loading mixed active content. - The Danger: An attacker who tampers with an unencrypted JavaScript file could steal authentication session cookies, capture passwords, or rewrite the DOM entirely.
2. How to Locate Mixed Content in Chrome DevTools
Never waste time manually searching through your database or template files looking for broken URLs. Your browser's console reports the exact file name and line number:
- Open your website in Google Chrome.
- Open Chrome DevTools by pressing
F12orCmd+Option+I(macOS). - Click on the Console tab.
- Filter by warnings and errors. You will see bright yellow/red alerts:
Mixed Content: The page at 'https://example.com/guide' was loaded over HTTPS, but requested an insecure element 'http://cdn.example.com/banner.jpg'. This request has been automatically blocked. - DevTools will display a clickable link directly to the HTML line or script where the insecure asset is declared.
3. How to Fix Mixed Content
Solution 1: Switch to Protocol-Relative or Absolute HTTPS URLs
Update hardcoded database records or template references from:
<!-- INSECURE: Triggers mixed content -->
<img src="http://example.com/images/logo.png" alt="Logo" />
<!-- FIXED: Explicit HTTPS -->
<img src="https://example.com/images/logo.png" alt="Logo" />
<!-- FIXED: Root-relative path (inherits the current secure protocol) -->
<img src="/images/logo.png" alt="Logo" />
Solution 2: The Magic CSP Header (upgrade-insecure-requests)
If your website contains thousands of historical blog posts with legacy http:// image embeds, manually editing every post is impractical.
You can instruct modern web browsers to automatically rewrite all insecure HTTP asset requests to secure HTTPS on the fly using a Content Security Policy (CSP) directive.
Via HTML Meta Tag (Place inside <head>):
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />
Via Nginx Server Header (Recommended):
add_header Content-Security-Policy "upgrade-insecure-requests" always;
When this header is present, if the browser encounters http://example.com/old-image.jpg, it silently upgrades the protocol to https://example.com/old-image.jpg before making the network request. If the destination server supports HTTPS, the asset loads securely and the padlock is instantly restored!
4. Third-Party CDNs and External APIs
What if the asset causing the mixed content error is hosted on an external third-party domain (e.g., an outdated weather widget, font library, or affiliate badge) that does not support HTTPS?
- The browser will refuse to load the asset over plain HTTP.
- If the external vendor does not provide an SSL certificate for their CDN, you have two choices:
- Download the asset (e.g., image or font) and host it locally on your own HTTPS server.
- Proxy the request through your own server or edge worker.
- Replace the vendor with a modern, secure alternative.
Audit your site quarterly, enforce upgrade-insecure-requests, and enjoy a permanent, trustworthy security padlock across every page.