How to fix mixed content warnings

Mixed content is what happens when a page loaded securely over HTTPS still pulls in a resource — an image, a script, a stylesheet, a font — over plain, unencrypted HTTP. The page itself is on a secure connection, but part of what it loads is not, and the browser has to decide what to do about the part that broke the guarantee.

What it looks like

Depending on the browser and the type of resource, mixed content shows up in one of two ways. Passive mixed content — typically images — is often still loaded but flagged, with the browser showing a broken or modified padlock icon and a warning if you inspect the connection. Active mixed content — scripts, stylesheets, iframes — is usually blocked outright by modern browsers rather than loaded, which means the resource simply does not appear or run, sometimes with no obvious warning beyond the browser's developer console.

Why it happens

The near-universal cause is a site that was originally built, or ran for a period, as HTTP-only and was later switched to HTTPS. Anything written into the database or the page templates during that earlier period — an image address saved by a page builder, a script tag pasted from a third-party tool, a link inside a blog post — was saved as a full http:// address at the time, and switching the site's own address to HTTPS afterwards does not go back and rewrite content that already exists. Every one of those old, hardcoded addresses is now a mixed content problem waiting to be found.

Finding every instance

The most reliable way to find mixed content is to open your browser's developer tools while viewing the affected page, switch to the console tab, and reload. Browsers report each blocked or flagged resource individually, by its exact address, which tells you precisely what to search for rather than guessing.

Fixing it in the database

If your site is built on a CMS storing content in a database, the fastest fix for content-level mixed content is a search and replace across the database: replacing every stored instance of http://yourdomain.com with https://yourdomain.com. Use a tool built for the purpose rather than editing raw database tables by hand — a plain text search and replace on serialised data (a format some platforms use to store structured settings inside a single database field) can corrupt it if it changes the recorded length of the string without updating the length marker stored alongside it.

Fixing it in code and templates

For addresses hardcoded into theme files, custom code, or pasted script snippets, the fix is a direct edit: find the http:// reference and change it to https://, or better, use a protocol-relative or root-relative address so it never hardcodes a protocol again.

• Protocol-relative: //yourdomain.com/image.jpg — automatically matches whichever protocol the page itself was loaded with.
• Root-relative: /images/photo.jpg — no domain or protocol at all, and the correct choice for anything hosted on the same site.

Either of these is more robust than hardcoding https:// directly, because it removes the chance of the same problem recurring if the site is ever moved to a different domain.

A stopgap while you find everything

If you need the visible symptoms handled immediately while you track down every instance, a Content-Security-Policy header can instruct the browser to silently upgrade insecure requests to HTTPS automatically:

Content-Security-Policy: upgrade-insecure-requests

This is a genuine stopgap, not a fix — it only works for resources that are actually reachable over HTTPS at the same address, and it does nothing about a resource that only exists on an HTTP-only server elsewhere. Treat it as buying time while you correct the underlying addresses, covered further in how to add security headers to your site.

Confirming it is actually fixed

Reload the page with developer tools open and confirm the console shows no further mixed content warnings. Check a representative sample of pages, not just the homepage, since different page types on the same site often pull in different combinations of images, scripts and embeds. If warnings persist after a database search and replace, the remaining instances are almost always in template files or a cached version of the page rather than the database — clear any page cache before assuming the fix has not worked.