Mixed content warnings and how to fix them

Symptoms

The page loads over https, the padlock bar still appears, but the browser warns "Mixed Content" and some images, scripts, fonts, or embed frames either never load or are replaced. In Firefox the padlock starts with a warning symbol; Chrome blocks active content outright and may auto-upgrade passive content. The site looks broken in unpredictable places: the gallery is empty, a form endpoint fails, or a video placeholder remains.

What the warning actually means

A page loaded over https cannot safely request http in most cases. The http request would travel unencrypted, which defeats the transport security you added at the top level. Browsers split the danger into two groups:

| Resource type (blocked) | Examples |

| Passive, usually auto-upgraded | Images, videos, audio |

| Active, always blocked | <script>, <link stylesheet>, fetch(), XMLHttpRequest, iframe through http, @font-face through http |

Active content can read and change the page, so browsers refuse it at the network layer. A single banner ad loaded over http with a script active can produce the padlock and console errors even when the rest of the page is clean HTTPS.

How to find the offenders

1. Open the page in the browser, then open developer tools (F12) and the Console tab.
2. Filter Console messages for "mixed content" or "blocked". The messages list the exact URL of the offending resource.
3. Open the Network tab, filter for http:// scheme requests, and disable cache (checkbox) before reloading.
4. Repeat on several pages, since one shared header or widget loads the same resource everywhere.

How to fix it

1. Change the source URL

• If the site is fully https now, the assets should load over https too. Update the references from http://example.com/... to https://example.com/... in HTML, CSS, JS, and database content.
• Better: use protocol-relative or scheme-relative URLs (//example.com/...) or built-in absolute URLs that inherit the page scheme, so the page never hard-codes a scheme and cannot regress after a scheme change.

2. Re-issue the resource itself

• An image, font, or script may simply not exist on https because the CDN or the server only hosts the plain copy. Then upload, re-link, or serve the https copy of the file.
• Content Management System media, e.g. WordPress uploads, normally needs the siteurl and home settings to point to https:// and a search of the database (wp_options) for old http URLs.

3. Add a Content Security Policy header

A strict upgrade-insecure-requests directive tells the browser to rewrite http requests to https automatically. Example header for an nginx config:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

This is a safety net, not a rewrite of the source. If an asset does not exist over https it still fails, and the console shows why.

4. Catch it across the whole site

• Add a preflight before you go live: crawl the site (or inspect the template layer) specifically for hard-coded http:// URLs in text inputs, ad slots and iframes.
• Force all browsing to https at the load balancer or web server layer from day one, so no page is ever served over http while its assets are still referenced on http.

Prevention

• Keep every asset URL scheme-free, and let the scheme follow the page.
• Never trust a single "it works now" check on one page; mixed content hides in tables, galleries and third-party widget folders that did not change when you flipped https.
• If the resource must come from a third-party domain, confirm that domain serves over https itself, because the page's upgrade cannot fix a provider that only listens on http.

The redirect article explains how to make the whole site live on https so new pages cannot regress.