How to Fix Mixed Content Warnings

Your site loads over HTTPS, but the padlock is missing or the console is full of warnings. The usual cause is mixed content: a secure page pulling in some resources over insecure http://. Here’s why it breaks the padlock and how to fix it for good.

Why one HTTP resource breaks the padlock

The padlock is a promise: everything on this page arrived securely. The moment a single resource loads over HTTP, that promise is broken — an attacker on the network could tamper with that one file. Rather than show a padlock that isn’t fully true, the browser downgrades the indicator or blocks the resource outright. So even a correct SSL/TLS certificate won’t give you a clean padlock if the page itself references insecure content.

Active vs passive mixed content

Browsers treat two categories differently based on how dangerous each is.

Passive (or “display”) mixed content

Images, audio and video loaded over HTTP. These can’t execute code, so the risk is lower — an attacker could swap an image but not hijack the page. Browsers often still load these but remove the padlock and log a warning. Increasingly they auto-upgrade them to HTTPS where possible.

Active mixed content

Scripts, stylesheets, iframes, fonts and XHR/fetch requests over HTTP. These can alter the whole page, so they’re dangerous. Modern browsers block them entirely. That’s why an insecure <script> can make part of your site simply stop working — a broken menu, a missing widget, a dead form.

Type	Examples	Browser behaviour
Passive	img, audio, video	Padlock removed; often auto-upgraded
Active	script, css, iframe, font, fetch	Blocked outright

Step by step: finding and fixing it

1. Find the offenders. Open the page, launch your browser’s developer console, and look for “Mixed Content” messages — each names the exact HTTP URL. A site scan surfaces them too.
2. Fix hardcoded links. Update http:// to https:// in your templates, theme files and content. On a CMS, this often lives in the database as well as the theme.
3. Handle third-party resources. If an external asset has no HTTPS version, host it yourself or replace it. Never leave an insecure third-party script.
4. Update the database (CMS sites). On platforms like WordPress, run a search-and-replace across post content and settings to swap old http:// URLs for https://.
5. Re-scan. Confirm the console is clean and the padlock is back.

The CSP safety net

Once the obvious offenders are gone, add a Content Security Policy directive that tells the browser to automatically upgrade any remaining HTTP references to HTTPS before requesting them:

Content-Security-Policy: upgrade-insecure-requests

This catches stray URLs you missed — an old image link in a forgotten post, for instance — and rewrites them on the fly. It’s a backstop, not a substitute for fixing the source, but it’s a valuable one. Learn more in our CSP guide and the wider security headers checklist.

Prevent it coming back

After you’re clean, make sure you redirect HTTP to HTTPS site-wide and use protocol-relative or absolute https:// links in new content. Adding HSTS further ensures browsers never even attempt an insecure request to your domain. Verify the whole picture with a free scan.

Frequently asked questions

Related guides