What Mixed Content Actually Is

When your website loads over HTTPS but serves individual resources over plain HTTP, browsers flag the page as having mixed content. The HTML document itself arrives securely, but embedded assets like images, stylesheets, scripts, or iframes load over an unencrypted connection. Modern browsers block or warn about these insecure requests because they create vulnerabilities that undermine the entire HTTPS protection model.

The security risk is real. An attacker performing a man-in-the-middle attack on the HTTP portion of your page can inject malicious scripts, replace images with phishing content, or redirect users to malware sites. Even though the main page loads over HTTPS, the HTTP resources create an attack surface that compromises user data and trust.

Active vs Passive Mixed Content

Browsers treat different resource types with different severity levels. Passive mixed content includes images, video, audio, and other media that cannot execute scripts or access the page context. Browsers load passive mixed content but display a warning icon in the address bar. The page functions normally, but the security indicator tells attentive users something is wrong.

Active mixed content includes scripts, stylesheets, iframes, web fonts, and XMLHttpRequest/Fetch requests. These resources can execute code, modify the DOM, and steal user data. Modern browsers block active mixed content entirely in most cases. A page loading a script over HTTP will have that script silently blocked, breaking functionality without any visible error message to the user.

Here is the breakdown by resource type:

Blocked outright: Scripts (script src), stylesheets (link rel="stylesheet"), iframes, XMLHttpRequest/Fetch requests
Blocked with console warning: Web fonts (@font-face), SVG images loaded via img or object tags in some browsers
Loaded with warning: Images (img src), video (video src), audio (audio src), object tags for media

How to Find Mixed Content on Your Site

The fastest detection method is your browser's developer console. Press F12, navigate to the Console tab, and load your HTTPS page. Any mixed content generates explicit warnings identifying the exact resource URL and line number causing the issue:

Mixed Content: The page at 'https://example.com/page' was loaded over HTTPS, 
but requested an insecure image 'http://example.com/image.jpg'. 
This content should also be served over HTTPS.

For automated detection across your entire site, use a crawling tool. Our mixed content checker crawls your pages and identifies every insecure resource reference, categorizing them by severity (active vs passive) and providing the exact source file and line number where each HTTP reference occurs.

In Chrome DevTools Network tab, filter by "Mixed" to see only insecure requests. The Protocol column shows http:// for each problematic resource. This visual approach helps you identify patterns, like a single CSS file referencing dozens of HTTP images, or a JavaScript snippet loading an HTTP analytics script.

Fixing Mixed Content with Relative URLs

The simplest fix converts absolute HTTP URLs to relative paths. Instead of referencing http://example.com/images/photo.jpg, use /images/photo.jpg. The browser resolves the relative path using the current page's protocol, automatically loading the resource over HTTPS when the page is secure:

<!-- Before: Forces HTTP -->
<img src="http://example.com/images/photo.jpg">

<!-- After: Inherits HTTPS from page -->
<img src="/images/photo.jpg">

Relative URLs also make your site portable across domains and protocols. If you ever switch domains or move from staging HTTP to production HTTPS, relative paths continue working without modification. Search your codebase for http:// references and replace them with relative paths wherever possible.

Protocol-Relative URLs

Protocol-relative URLs use double slashes instead of http:// or https://. The browser loads the resource using whatever protocol the current page uses. This was a popular fix before HTTPS became universal, but it has a significant drawback: if a user somehow loads your page over HTTP (typing the URL manually, clicking an HTTP link), the protocol-relative resources also load over HTTP.

<!-- Protocol-relative -->
<script src="//cdn.example.com/script.js"></script>

<!-- Explicit HTTPS (preferred) -->
<script src="https://cdn.example.com/script.js"></script>

Protocol-relative URLs are now considered outdated. Explicit HTTPS references are safer because they guarantee secure loading regardless of how the page was accessed. Search for //cdn references in your codebase and replace them with https://cdn to eliminate this class of mixed content permanently.

Content Security Policy Enforcement

A Content Security Policy header lets you enforce HTTPS for all resources at the server level. The upgrade-insecure-requests directive automatically upgrades any HTTP request to HTTPS before the browser makes it:

Content-Security-Policy: upgrade-insecure-requests

This directive tells the browser to rewrite all HTTP URLs to HTTPS automatically. It handles relative paths, absolute URLs, and even third-party HTTP references without modifying your HTML. For cases where you want to block mixed content instead of upgrading it, use the default-src directive:

Content-Security-Policy: default-src https: 'self'

Apply your CSP in report-only mode first to identify any resources that fail to load over HTTPS before enforcing it live:

Content-Security-Policy-Report-Only: upgrade-insecure-requests; 
  report-uri /csp-report

SEO Impact of Mixed Content

Google treats mixed content as a quality signal. A page with blocked active mixed content may render incorrectly, with missing styles, broken scripts, or invisible elements. If Googlebot encounters a broken page due to blocked mixed content, it indexes the broken version. Users who click through see a degraded experience, increasing bounce rates and reducing dwell time.

HTTPS is a confirmed ranking signal. While Google does not explicitly penalize pages with passive mixed content warnings, the combination of a poor user experience, potential rendering failures, and the security warning icon in the address bar creates measurable negative behavioral signals that impact rankings indirectly.

Check your Google Search Console for any mixed content issues Google has detected. The Security and Manual Actions report flags problematic pages. Additionally, our mixed content checker scans your entire site and prioritizes fixes based on severity, so you can address active mixed content (which breaks pages) before passive mixed content (which just displays warnings).

Fixing Mixed Content in Third-Party Scripts

Third-party scripts frequently reference HTTP resources you do not control. A social sharing widget might load HTTP badge images. An embedded map might use HTTP tile servers. An analytics script might beacon data to an HTTP endpoint.

Contact the third-party provider and request they update their HTTP references to HTTPS. Most reputable services (Google, Facebook, Twitter) have already migrated. For services that have not, evaluate whether the functionality justifies the mixed content risk. Replace non-essential third-party widgets that cannot load securely with alternatives that support HTTPS.

If you must use a third-party service that serves mixed content, request-or create-a proxy that fetches the resource through your server and serves it over HTTPS. This adds server load but eliminates the mixed content issue without removing the widget.