Why are images allowed but scripts blocked?

Scripts, stylesheets, and iframes are active (blockable) mixed content because they can rewrite the page, so browsers block them outright. Images, audio, and video are passive content that browsers now auto-upgrade to HTTPS and only fail if the host has no HTTPS.

Does upgrade-insecure-requests fix everything?

It rewrites http:// to https:// for your own subresources and same-origin navigation, but only works if those hosts actually serve HTTPS. It does not upgrade links to other origins, so it is not a replacement for HSTS.

It works locally but breaks in production. Why?

Mixed content only triggers when the page itself is loaded over HTTPS. A hardcoded http:// reference is harmless on a local HTTP build and gets blocked the moment the same page is served over HTTPS.

Views: 33

Mixed Content Blocked: Fix Insecure Resources on HTTPS Pages

Your HTTPS page loads but scripts or images are blocked as mixed content. Locate the http:// references, tell active from passive, and upgrade them safely.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The page is served over HTTPS, but the browser console reports Mixed Content and some scripts, styles, or images never load. The lock icon shows a warning, or interactive features quietly stop working.

Symptoms

The console shows Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure ... 'http://...'. This request has been blocked; the content must be served over HTTPS.
A script or stylesheet fails to load, so layout breaks or a feature stops responding.
Images, audio, or video silently fail when they reference http://.
It works on a local HTTP build and breaks only once deployed behind HTTPS.

Top 3 Causes

Hardcoded http:// URLs - Templates, CMS content, or build output reference http:// for scripts, styles, or media.
A third-party or legacy host without HTTPS - An embed, widget, or asset host you reference only serves over HTTP, so the upgraded request has nowhere to land.
TLS terminated upstream - A CDN or proxy (for example Cloudflare Flexible SSL) terminates HTTPS and forwards plain HTTP to the origin, so server-side code generates http:// absolute URLs.

Diagnose with DechoNet

HTTP Check to confirm the page is actually served over HTTPS, inspect redirect behavior, and review the Content-Security-Policy header that controls upgrading.
SSL Check to verify that the hosts serving your subresources present a valid certificate, since blocked active content and failed image upgrades both depend on the resource host supporting HTTPS.

Resolution Checklist

Open the browser console and list every http:// URL it flags - fix the source, do not rely on the browser to paper over it.
Change hardcoded http:// references to https:// or relative paths in templates, stylesheets, and application code.
Confirm each external host actually serves the file over HTTPS before switching its URL.
Add Content-Security-Policy: upgrade-insecure-requests to rewrite same-origin and subresource http:// requests to https://; it does not upgrade cross-origin navigation, so keep HSTS for that.
If a CDN or proxy terminates TLS, switch it to full/strict HTTPS to the origin so the app stops emitting http:// URLs.
Reload and re-check until the console is clean - active content (scripts, iframes, fetch) is blocked outright, while images and media are auto-upgraded and fail if HTTPS is unavailable.

When to Escalate

Escalate to the third-party vendor if an embedded widget or asset is only available over HTTP and you cannot self-host it over HTTPS.
Escalate to whoever owns the CDN or load balancer if TLS termination forces the origin onto HTTP and you cannot change the absolute URLs in the output.