Mixed Content & Secure Contexts
You ship a dashboard over https, the address bar shows the closed padlock, and one <script src="http://..."> you pasted months ago never runs. The page half-renders and the console prints one red line explaining the drop.
- ▸Your https page loads one http
<script>and it silently vanishes: dead in production, yet fine on localhost. - ▸The same http image upgrades to https and renders, but name its host by raw IP and it is blocked.
- ▸Serve the identical page over plain http and the camera stops existing: one flag flipped, every powerful API gone.
The dashboard arrived over https, and that single fact is now a promise the browser enforces. Every byte the page pulls in afterward, its images, its scripts, its data, should travel over a channel at least as protected as the page itself. The scheme of the top-level document sets a floor.
A subresource requested over plain http falls below that floor. When an https document loads an http subresource, the page is mixed content: a secure shell wrapped around an insecure filling. The name is literal, one page, two grades of channel.
The reason the browser cares is the single insecure hop. Anyone sitting on that http connection can read those bytes or rewrite them in flight, and whatever comes back lands *inside* a page the user believes is protected. The lock in the address bar would be a lie.
The boundary is worth pinning down, because it is a mismatch, not just "http somewhere." An http page loading http resources is not mixed content: there is no floor to fall below. An https page loading https resources is clean. Mixed content is exactly the pairing of a secure document with an insecure resource, and nothing else.