All posts
Security3 min readWatchFor Team

Mixed Content Warnings: what they are and how to fix them

Your site is on HTTPS, but the padlock has a warning — or images won't load. That's mixed content: a secure page pulling in insecure resources. Here's how to find and fix it.

Mixed Content Warnings: what they are and how to fix them

You moved your site to HTTPS, the padlock appeared, and all was well — until you noticed the padlock now has a little warning, or some images and scripts mysteriously stopped loading. Welcome to mixed content: a secure page that's loading insecure resources.

What mixed content is

Mixed content happens when a page served over HTTPS loads some resources over plain HTTP — an image, a script, a stylesheet, a font. The page itself is encrypted, but those individual resources aren't, which undermines the security the padlock promises.

Browsers don't like that, and they handle it in two ways:

TypeWhat it isBrowser response
PassiveImages, video, audio over HTTPOften loaded, but the padlock shows a warning
ActiveScripts, stylesheets, iframes over HTTPBlocked entirely — they don't load

That second row is why "some scripts/styles broke after going HTTPS" — the browser refused to load the insecure ones.

Why browsers block it

An insecure resource on a secure page is a real hole: an attacker on the network could tamper with that HTTP script and inject code into your otherwise-secure page. So browsers block active mixed content outright, and warn on passive — protecting your users (and your padlock's credibility).

How to find it

  1. Open the browser console. Mixed-content issues are logged explicitly: "Mixed Content: The page was loaded over HTTPS but requested an insecure resource …" — with the exact URL.
  2. Look for the padlock warning. A padlock with a caution icon means passive mixed content somewhere on the page.
  3. Search your code/content for hard-coded http:// URLs — in templates, in CMS content, in third-party embeds.

How to fix it

  • Change http:// to https:// for every resource you control. Most hosts and CDNs already serve HTTPS, so it's often just the protocol.
  • Use protocol-relative or absolute HTTPS URLs going forward, so new content doesn't reintroduce it.
  • Update third-party embeds to their HTTPS versions.
  • Use Content-Security-Policy: upgrade-insecure-requests as a safety net — it tells browsers to automatically try HTTPS for HTTP resources.
  • Fix it at the source (the CMS, the template) so it doesn't creep back with the next content edit.

Most common source: old content and templates with hard-coded http:// image and script URLs from before the HTTPS migration. A find-and-replace across content usually clears the bulk of it.

Keep it from coming back

Mixed content loves to sneak back in — a new blog post with an http:// image, a fresh third-party widget. Because it quietly breaks functionality (blocked scripts) and erodes the padlock, it's worth checking your pages for insecure resources as part of monitoring, so a regression shows up fast.

The bottom line

In one line
WhatA secure (HTTPS) page loading insecure (HTTP) resources.
EffectPadlock warning; active resources (scripts/styles) blocked.
FindThe browser console names every offending URL.
FixSwitch resource URLs to HTTPS; fix the source content.

Mixed content is the loose thread in an otherwise-secure page. Switch every resource to HTTPS, fix it at the template/CMS level, and your padlock goes back to meaning exactly what users think it does.

Related: How HTTPS works; inspect headers with the free HTTP header checker.

Share this article