What "Mixed Content" Means, and Why the Browser Blocked Your Image

You loaded a page over HTTPS, the lock is in the address bar, and yet an image is missing, a script did not run, or a whole widget failed to appear. Open the console and there it is: “Mixed Content: The page was loaded over HTTPS, but requested an insecure resource over HTTP. This request has been blocked.”

The page is secure. Something it asked for was not, and the browser refused to fetch it. That is the whole of a mixed-content error, and the fix is usually one character - but it helps to know why the browser is being so strict about a single missing image.

What “mixed” means here

A page served over HTTPS is delivered encrypted, and the padlock is a promise to the visitor that everything on it arrived that way. Then the page asks for a resource - an image, a script, a stylesheet, a font - using a plain http:// address. That resource would arrive unencrypted, over a connection anyone on the network can read or tamper with.

That is the mix: a secure page and an insecure request inside it. The browser will not quietly break the promise the padlock made, so it steps in. What it does next depends on how dangerous the resource is.

Blocked or just warned

Not all mixed content is treated the same, and this is the part that explains why sometimes an image loads with a warning and sometimes a script vanishes entirely.

Active content is blocked outright. Scripts, stylesheets, iframes and anything that can change the page or run code. If one of these is requested over HTTP, the browser refuses to load it at all, because a tampered script could rewrite the whole page. This is the one that breaks features: a payment widget, an analytics tag, a map that never appears.

Passive content is loaded, with a warning, or upgraded. Images, video and audio - things that display but cannot run code. Older browsers loaded these over HTTP and downgraded the padlock to warn you. Modern ones increasingly try to fetch them over HTTPS instead, and only fail visibly if that does not work. So a missing image and a dead script are often the same underlying fault, showing up with different severity.

How to find and fix it

The console names the exact resource. Read the URL it is complaining about, and the fix is nearly always to request that resource over https:// instead of http://.

• If the resource has an HTTPS version, use it. Most do; changing http:// to https:// in your own markup is the entire fix. If you have many, a protocol-relative //example.com/... or a content-security-policy upgrade-insecure-requests directive fixes them in bulk.
• If the resource has no HTTPS version, you cannot include it. A third-party asset served only over HTTP has to be replaced, proxied through your own HTTPS server, or dropped. There is no browser setting that makes this safe, and telling a visitor to disable the protection is not a fix.
• Watch for it in data, not just markup. A URL stored in your database, returned by an API, or pasted into a rich-text field is the usual reason mixed content survives a migration to HTTPS: the templates were fixed and the content was not.

A request that fails this way looks a lot like one that failed for other reasons, which is why the console line matters. If the console instead says the request was blocked by CORS policy, or comes back as TypeError: Failed to fetch, that is a different problem with a different fix - the first word of the error is doing a lot of work.

Why a screenshot is not enough to report one

A mixed-content failure is invisible in a screenshot: the page just has a gap where something should be, and the reason lives in the console, which the person reporting it has almost certainly not opened. “The image is missing” and “the checkout widget didn’t load” are the reports you get, and neither one carries the console line that says exactly which HTTP resource on an HTTPS page was refused.

The console log it captures is where the mixed-content message lives, named resource and all, so whoever picks up the report can see which insecure URL to fix without having to reproduce the page and open developer tools to find it.

In one paragraph

Mixed content is an insecure http:// resource requested by a secure https:// page, and the browser blocks it - completely for scripts and other active content, more gently for images - rather than break the promise the padlock makes. The fix is almost always to request the resource over HTTPS, in your markup and in your stored data both; if it has no HTTPS version it cannot be included safely at all. And because the failure is a silent gap on the page with the reason hidden in the console, it is worth capturing rather than describing.