Mixed content checker

Mixed content happens when a page served over HTTPS references subresources over plain HTTP — images, scripts, stylesheets, iframes, video, audio, favicons. The page itself is encrypted, but those subresources aren't: an attacker on the network can intercept, modify, or replace them. Modern browsers now handle mixed content aggressively: scripts, stylesheets, and iframes over HTTP are blocked outright, while images and media are auto-upgraded to HTTPS (and blocked if the HTTPS version fails). In either case, the page visibly degrades — missing styles, broken layouts, or the "not secure" padlock warning that users read as "don't trust this site".

What this tool checks

• Scripts — <script src="http://..."> (active; blocked)
• Stylesheets — <link rel="stylesheet" href="http://..."> (active; blocked)
• Iframes — <iframe src="http://..."> (active; blocked)
• Form actions — <form action="http://..."> (active; credentials travel unencrypted)
• Object / embed — legacy plugin embeds over HTTP (active; blocked)
• Images — <img src> and <img srcset> (passive; upgraded or blocked)
• Video / audio — including <source> inside <video> / <audio> (passive)
• Picture source — <picture> <source srcset="http://..."> (passive)
• Favicon — <link rel="icon"> pointing over HTTP (passive)

Active vs passive mixed content

• Active — scripts, stylesheets, iframes, form actions, object/embed. Browsers block these entirely on HTTPS pages. Consequence: the page visibly breaks. Tampering would let an attacker execute code on behalf of your site, so the block is absolute.
• Passive — images, video, audio, favicons. Less direct attack surface (an attacker can swap the image but can't run code). Chrome and Safari auto-upgrade these to HTTPS since 2023, blocking if the upgrade fails. The padlock is downgraded to "not secure" regardless.

Good vs bad examples

Good — absolute HTTPS URL:

<img src="https://cdn.example.com/photo.jpg">

Good — protocol-relative URL (inherits the page's protocol, so it's HTTPS here):

<img src="//cdn.example.com/photo.jpg">

Good — relative URL (always inherits the page's protocol):

<img src="/images/photo.jpg">

Bad — explicit HTTP on an HTTPS page (active mixed content, blocked):

<script src="http://legacy-cdn.com/jquery.js"></script>

Bad — form posting over HTTP (credentials travel unencrypted):

<form action="http://old-backend.example.com/login">...</form>

Bad — HTTP in srcset (often missed because srcset isn't reviewed like src):

<img srcset="http://cdn.com/1x.jpg 1x, http://cdn.com/2x.jpg 2x">

How to fix mixed content

• Replace http:// with https:// wherever you control the source. Search your codebase for http:// (with colon-slash-slash) — protocol-relative // is fine.
• Use relative or protocol-relative URLs when the resource is on the same domain or a domain that serves both protocols.
• Add CSP upgrade-insecure-requests — a transitional measure that tells the browser to auto-upgrade every HTTP subresource. Useful while migrating; not a substitute for fixing the source.
• Check third-party integrations — ad networks, widgets, analytics, legacy CDNs. If a third party only serves HTTP, replace or proxy through your HTTPS origin.

Common mistakes

• HTTP URLs in srcset or <source> — easy to miss because search-and-replace tools often only check src
• Form actions still pointing at HTTP — a credential-level security issue, not just a padlock warning
• HTTP in favicon link — small but still flags mixed content in DevTools
• Hardcoded HTTP URLs in CMS content — legacy blog posts written when the site was HTTP; bulk search-and-replace in the database fixes most of these
• Third-party iframes on legacy CDNs — the iframe gets blocked, the widget disappears silently
• Relying only on upgrade-insecure-requests — it works, but only for browsers that honor CSP, and only for resources that exist on HTTPS. Fix the source too.