What Is Mixed Content?

How Mixed Content Works

A page delivered over HTTPS travels through an encrypted, tamper-resistant channel. That guarantee only holds if everything on the page comes the same way. When a secure page loads a resource over plain HTTP — an image, a script, a stylesheet, a font, an iframe — that single request opens a hole an attacker on the network can read or rewrite. That mismatch is mixed content: a secure document quietly pulling in insecure parts.

Browsers no longer treat all of those parts the same way. As MDN describes it, they mitigate the risk by auto-upgrading image, video, and audio requests from HTTP to HTTPS, and blocking insecure requests for every other resource type — scripts, stylesheets loaded via <link>, iframes, web fonts, and fetch() or XMLHttpRequest calls. The logic is about blast radius: a script or stylesheet can rewrite the whole page, so it is too dangerous to allow, while a hijacked image can only corrupt itself. One quirk to remember is that even an upgradable request gets blocked outright if its host is a raw IP address rather than a domain name.

This split has older names still common in tooling and audits. Earlier versions of the specification called the blockable types active mixed content and the upgradable media types passive — or optionally blockable — mixed content. When a report flags “active mixed content,” it means the browser is blocking a script or stylesheet, which is why the visible symptom is usually a broken layout rather than a warning.

Fixing and Preventing Mixed Content

The correct fix is to serve every resource over HTTPS from the source: update the hardcoded http:// URLs in your templates, theme files, and content database to https://. As a fast, comprehensive backstop, the Content Security Policy directive upgrade-insecure-requests instructs the browser to rewrite every insecure subresource request to HTTPS before it is sent — covering the blockable types the browser would otherwise refuse. It is the reason mixed content is so tightly bound to any HTTP-to-HTTPS migration: the page moves to HTTPS, but stale asset references left behind in the markup do not.

Example of Mixed Content

The clearest documented milestone is Chrome’s phased crackdown, announced on the Google Online Security Blog in October 2019 in a post titled No More Mixed Messages About HTTPS. Google laid out a version-by-version rollout that hardened how the browser handles mixed content and made the “upgrade or block” model the default.

The schedule was specific. In Chrome 79 (December 2019), Chrome began auto-upgrading mixed resources to https:// so pages kept working when the secure version existed. In Chrome 80 (January 2020), mixed audio and video were auto-upgraded and blocked if they failed to load over HTTPS, while mixed images still loaded but triggered a “Not Secure” chip in the address bar. In Chrome 81 (February 2020), mixed images were auto-upgraded and blocked on failure too. The rollout turned what had once been a soft warning into enforced behavior: by early 2020, insecure scripts and styles were simply gone from secure pages, and insecure media was silently upgraded.

For anyone running a site, the lesson is that mixed content stopped being a cosmetic browser notice years ago and became a rendering issue. A stylesheet or script that a browser blocks does not degrade gracefully — it disappears, and the page can look broken to both users and the crawlers that render pages to evaluate them. Serving every resource over HTTPS is the baseline the modern web already assumes.

Frequently Asked Questions

The Bottom Line

Mixed content is the loose thread in an otherwise-secure page: the padlock says HTTPS, but a few resources still travel over plain HTTP. Browsers no longer look the other way — they quietly upgrade media requests and hard-block scripts, styles, and frames, which is why a half-migrated page often renders broken rather than merely warned. The durable fix is to serve every resource over HTTPS at the source, with upgrade-insecure-requests as the safety net.