<b>Why does a browser silently load a mixed-content image but block a mixed-content script?</b>

<b>Why does a browser silently load a mixed-content image but block a mixed-content script?</b>

Mixed content occurs when an HTTPS page pulls a subresource over plain HTTP. Browsers do not treat all such resources identically; the distinction between passive and active mixed content is a deliberate threat-model decision codified in the W3C Mixed Content specification.

Passive (or "display") mixed content — images, audio, video — cannot alter the rest of the page's DOM or read its data. A network attacker tampering with an HTTP image can, at worst, swap the picture. Historically browsers loaded these with a warning indicator. The damage is bounded.

Active mixed content — scripts, stylesheets, iframes, fetch/XHR, WebSocket — executes in the page's origin. An attacker who rewrites an HTTP-loaded gains full control: stealing cookies, rewriting the DOM, exfiltrating form input. Because the blast radius is the entire origin, browsers block active mixed content outright, with no user override in modern engines.

The trajectory is toward eliminating the distinction. The Upgrade-Insecure-Requests CSP directive and autoupgrading (browsers silently rewriting http:// subresource URLs to https://) are closing the passive loophole, since a CSS file can leak data via background-image requests — blurring the passive/active line.

Evidence vs. speculation: the passive/active split is normative in the W3C spec; the autoupgrade rollout is the empirical direction of travel, not a guarantee for legacy resources.

<b>Further reading:</b> W3C Mixed Content (CR); CSP Level 3, upgrade-insecure-requests.

<b>Bottom line:</b> The split tracks blast radius — passive content can deface, active content can own the origin; rely on CSP upgrade directives rather than the browser's shrinking tolerance for either.