Mixed Content Checker Guide: Find Insecure Page Resources

A page served over HTTPS is supposed to be private and tamper-resistant, but that promise breaks if the page itself loads some of its parts over plain HTTP. That situation is called mixed content: the main page is secure, yet images, scripts, stylesheets, or other resources arrive unencrypted, where they can be observed or altered in transit. The Mixed Content Checker scans a page's resource list for those insecure loads, so you can find them all instead of discovering them one at a time from browser warnings. It is a format and content check on the page or list you supply, describing what it finds; it does not change your site for you, and fixing the loads is a separate step.

Mixed content comes in two kinds, and browsers treat them very differently. Active mixed content includes scripts, stylesheets, and other resources that can change how the page behaves, and browsers generally block it outright, which means parts of the page simply stop working for visitors. Passive mixed content includes images, audio, and video, which cannot directly change page behaviour, so browsers usually load them but downgrade the page's security indicators, showing a warning instead of the full secure padlock. Both kinds weaken the page, but active mixed content is the urgent one, because it can break functionality entirely, while passive mixed content is the embarrassing one, because visitors see a security warning on a page you believed was secure. A checker should report both, labelled by kind, so the urgent fixes come first.

The causes are usually mundane. A page built years ago may reference images with full http addresses baked into its content. A third-party widget or advertising script may load its own resources over HTTP. A content management system may store absolute URLs from before the site moved to HTTPS, so every old post carries insecure references. A theme or plugin may load a font or a script from an HTTP address. In each case the fix is the same in principle: change the reference to HTTPS, or to a protocol-relative form where appropriate, or replace the resource with one served securely. The hard part is finding every reference, because a page can load resources indirectly: a stylesheet can reference a font, a script can inject an image, and a single missed reference keeps the warning alive.

Worked example

Take a sample page, with values clearly labelled as an illustration. A checker scans the page and finds 14 external resources in total: 10 loaded over HTTPS and 4 over HTTP. Of the 4 insecure loads, 1 is a script, which is active mixed content, and 3 are images, which are passive mixed content. The insecure share is 4 divided by 14, or about 29 percent of the page's resources, which is enough to break the script-dependent feature and to downgrade the security indicator. Fixing the script first restores the broken feature, and fixing the 3 images restores the full secure indicator. After the fixes, insecure loads fall from 4 to 0, and the secure share rises from 10 out of 14, or about 71 percent, to 14 out of 14, or 100 percent. The team then searches the site's content database for the string "http://" in image references and finds 6 more posts with the same pattern, fixing them in the same session rather than waiting for visitors to report warnings one post at a time. The lesson is to fix the pattern, not just the page: a checker finds the instances, but a database search finds the cause.

Mistakes to avoid

The first mistake is fixing only the resources the browser visibly blocks and ignoring passive images, which leaves the security warning in place. The second is fixing a page by hand while the same insecure references remain in the database, so the next edit or import brings them back. The third is assuming a page is clean because it shows no warning on one browser, when another browser may report it differently or block different resources. The fourth is replacing an insecure third-party resource with a copy hosted without permission or without updates, which trades a security problem for a licensing and maintenance problem. The fifth is treating the checker as a one-time audit: every new post, widget, or plugin can reintroduce mixed content, so the check belongs in the publishing routine, not in a single cleanup day.

Putting it into practice

Run the checker on your most important pages, fix active content first, then passive content, then search your content for the underlying pattern and fix it at the source. Re-check after every theme, plugin, or widget change, since third-party code is a frequent source of new insecure loads. For related tools, the HTTPS Checker verifies the site's overall HTTPS setup, the HTTP Headers Checker reviews the security headers that accompany the page, and the companion guide on the HTTPS Checker explains HTTPS verification in depth. Mixed content is a small defect with an outsized effect: one insecure script can break a page, and one insecure image can cost it its secure badge.

Key points

  • Mixed content is a secure HTTPS page loading some resources over plain HTTP, which weakens privacy and integrity
  • Active mixed content, such as scripts, is blocked by browsers and can break features, while passive content, such as images, downgrades security indicators
  • Fix the pattern at its source, such as stored HTTP references in content, not just the single page the checker flagged
  • Re-check after every theme, plugin, or widget change, since third-party code often reintroduces insecure loads

In short: find every insecure load, fix active content first, remove the underlying pattern, and make the check part of publishing.