Mixed Content Warnings Explained

Why an HTTPS page can still trigger security warnings, and how to track down the insecure resource causing it.

Core Concept

Mixed content occurs when an HTTPS page loads a resource — a script, image, or stylesheet — over plain, unencrypted HTTP, undermining the security guarantee of the page as a whole.

Browsers flag this because an attacker positioned on the network can tamper with the insecure resource even though the main page itself is properly encrypted.

Insight: A page's HTTPS padlock only guarantees the top-level document is encrypted — every embedded resource needs its own HTTPS connection to be genuinely secure.

Active vs Passive Mixed Content

Browsers distinguish between two severity levels of mixed content.

Active mixed content — scripts, stylesheets, iframes that can alter page behavior
Passive mixed content — images, video, audio that can't execute code
Active content is typically blocked outright; passive is often just flagged

Active Content Gets Blocked

Modern browsers block active mixed content by default, since a compromised script or stylesheet could fully alter page behavior or steal data.

Common Causes of Mixed Content

Mixed content frequently sneaks in through overlooked sources rather than deliberate misconfiguration.

Hardcoded HTTP URLs in legacy content or templates
Third-party embeds or widgets still served over HTTP
CDN-hosted assets referenced with an absolute HTTP URL

Limitation: Migrating a site to HTTPS doesn't automatically update every hardcoded HTTP reference buried in older content or third-party integrations.

Finding Mixed Content Sources

Browser developer tools directly flag mixed content warnings in the console, making them straightforward to locate on a page-by-page basis.

For site-wide audits, automated crawlers can systematically check every page for embedded HTTP resource references.

Console Warnings

Browser developer tools console output typically points directly to the specific insecure resource URL causing a mixed content warning.

Fixing Mixed Content Issues

Resolution generally involves updating references to use HTTPS consistently.

Update hardcoded URLs to use HTTPS explicitly
Use protocol-relative or absolute HTTPS URLs consistently
Replace or remove third-party embeds that don't support HTTPS

Insight: The Content-Security-Policy directive upgrade-insecure-requests can serve as a stopgap, automatically upgrading HTTP resource requests to HTTPS where possible.

Real-World Implementation

Mixed content remediation is a common step in any HTTPS migration project.

Site migrations running full mixed-content audits before launch
CMS platforms scanning for and flagging insecure embedded resources
CSP upgrade-insecure-requests deployed as a transitional safeguard

Because mixed content issues degrade the actual security benefit of HTTPS, resolving them fully is as important as enabling HTTPS in the first place.

Common Mistakes to Avoid

A few common mistakes leave mixed content issues unresolved after an HTTPS migration.

Assuming an HTTPS migration automatically updates every hardcoded HTTP reference.
Overlooking third-party embeds or widgets still served over plain HTTP.
Treating passive mixed content warnings as unimportant compared to active content.
Failing to run a full site-wide crawl to catch mixed content across every page.
Not using CSP's upgrade-insecure-requests as a transitional safeguard during migration.
Overlooking mixed content in email templates linking back to a site's HTTPS pages.
Assuming a content management system automatically updates all embedded resource URLs.
Failing to check third-party analytics or tracking scripts for lingering HTTP references.
Overlooking that some browser extensions can inject their own mixed content unintentionally.
Assuming mixed content issues are limited to a site's own first-party resources.
Failing to review server-side rendered content for embedded HTTP references.
Overlooking that some legacy iframe embeds are particularly resistant to straightforward HTTPS updates.

Best Practices Checklist

These practices help fully resolve mixed content issues after migrating to HTTPS.

Run a full site-wide crawl to catch every embedded HTTP resource reference.
Update hardcoded URLs to HTTPS explicitly rather than leaving legacy references in place.
Replace or remove third-party embeds that don't support HTTPS.
Deploy CSP's upgrade-insecure-requests as a transitional safeguard during migration.
Treat passive mixed content as worth fixing too, not just the actively blocked active content.
Audit email templates for embedded HTTP resource links pointing to your own site.
Verify a CMS migration actually updated all embedded resource URLs, rather than assuming it did.
Check third-party analytics and tracking scripts specifically for HTTP references.
Recognize that browser extensions can sometimes introduce mixed content independent of site code.
Extend mixed content audits to include content sourced from third parties, not just first-party resources.
Review server-side rendered content specifically for any embedded HTTP references.
Budget extra time for legacy iframe embeds that resist straightforward HTTPS migration.

Frequently Asked Questions

Frequently asked questions about mixed content warnings.

Why does an HTTPS page still show a security warning?

Because it's loading one or more resources over plain HTTP, undermining the security guarantee of the page as a whole.

What's the difference between active and passive mixed content?

Active content, like scripts, can alter page behavior and is typically blocked outright, while passive content, like images, is often just flagged.

Does migrating to HTTPS automatically fix mixed content?

No — it doesn't automatically update hardcoded HTTP references buried in older content or third-party integrations, which need separate remediation.

How can I find every source of mixed content on a site?

Browser developer tools flag it page by page, while automated crawlers can systematically check an entire site at once.

Can CSP help during a mixed content cleanup?

Yes — the upgrade-insecure-requests directive can automatically upgrade HTTP resource requests to HTTPS as a stopgap during migration.

Can email templates cause mixed content issues?

Indirectly — while not a browser mixed content warning itself, embedded HTTP links in emails pointing to your site can reflect the same underlying URL hygiene gap.

Does a CMS migration to HTTPS fix embedded resource URLs automatically?

Not always reliably — it's worth verifying directly rather than assuming every embedded URL was updated during the migration.

Are third-party analytics scripts a common source of mixed content?

Yes — older or unmaintained tracking scripts sometimes still reference HTTP endpoints, making them worth checking specifically.

Can browser extensions cause mixed content warnings unrelated to site code?

In some cases yes, though this is distinct from and shouldn't be confused with actual site-caused mixed content issues.

Should third-party embedded content be included in mixed content audits?

Yes — third-party widgets and embeds are a common and easily overlooked source of mixed content beyond a site's own first-party code.

Are some mixed content sources harder to fix than others?

Yes — legacy iframe embeds from third parties can be particularly resistant to a quick HTTPS update, sometimes requiring a full replacement.

Check for Mixed Content Issues

Run an SSL check to help identify insecure resources loading on an HTTPS page.

Launch Tool →