Mixed Content Is Still Breaking Sites in 2026

Mixed content happens when an HTTPS page loads sub-resources — scripts, stylesheets, images, iframes — over plain HTTP. It sounds like a minor issue, but browsers treat it seriously. Active mixed content (scripts, stylesheets) is blocked entirely by modern browsers, which can break your site's functionality. Passive mixed content (images, video) may still load but shows security warnings to users.

Why it still happens

The most common cause is migrating a site to HTTPS without updating all internal references. A hardcoded http:// URL in a template, a CMS field storing an absolute URL, a third-party widget loaded over HTTP, or an embedded iframe pointing to an HTTP page. It only takes one to trigger the mixed content warning. Sites that have been around for years accumulate these references in blog posts, product pages, and forgotten templates.

Active vs. passive mixed content

Active mixed content includes scripts, stylesheets, iframes, and fetch/XHR requests. These are blocked by all modern browsers because a man-in-the-middle attacker could modify them in transit and take full control of the page. If your site depends on an HTTP-loaded script, it will silently fail. Passive mixed content includes images, audio, and video. These are typically still loaded but trigger a warning, and the browser may downgrade the padlock icon.

How to find mixed content

Browser DevTools will flag mixed content in the Console tab, but only for the specific page you're viewing. For a site-wide audit, you need to crawl every page. Look for any src, href, or action attribute pointing to an http:// URL. The Content-Security-Policy header can also help — set upgrade-insecure-requests to automatically rewrite HTTP URLs to HTTPS at the browser level.

Content-Security-Policy: upgrade-insecure-requests

This header is a safety net, not a permanent fix. It tells the browser to try HTTPS for any HTTP resource, but the resource still needs to actually be available over HTTPS for this to work. Fix the URLs at the source.

Common fixes

For your own resources, do a find-and-replace for http:// to https:// across your codebase and database. For third-party resources, check if the provider supports HTTPS — most do now. If they don't, find an alternative or host the resource yourself. For user-generated content in a CMS, run a database migration to update stored URLs. WordPress plugins like Better Search Replace make this straightforward.

Scan for mixed content

KrakenProbe scans your page for every sub-resource loaded over HTTP and tells you exactly which URLs need updating. Run a free scan and fix mixed content before your users see browser warnings.