Mixed Content Audit

What it does

The Mixed Content Audit fetches an HTTPS URL, parses the HTML, and lists every resource that loads over plain HTTP — <img>, <script>, <link>, <iframe>, <video>, <audio>, <source>, <embed>, <object>, <form>, plus url() references inside inline <style> blocks. Each issue is classified as active (high severity) or passive (medium severity) — active mixed content is blocked entirely by browsers; passive content loads but degrades the security indicator.

Common situations

You have just enabled HTTPS on a site and the security indicator (the lock icon) is missing or warning even though the cert is valid. Run the audit; mixed content is almost always the cause. Even a single <img src="http://..."> on a page is enough to break the security indicator.

You have migrated a site from one CDN to another and image URLs in the database still point at the old CDN’s HTTP URLs. The audit surfaces them quickly so you can update the references.

A WordPress site has been on HTTPS for years but you keep seeing scattered HTTP references in old content (embedded images from third parties, hard-coded scripts, inline styles). The audit pinpoints exactly which resources need attention.

A page-builder template has been updated and silently introduced HTTP-loaded scripts (typically from analytics or A/B test tools that haven’t updated their integration code). The audit catches them; security audit tools would also flag them but more slowly.

You are auditing a competitor’s HTTPS posture. If they have mixed content issues, browsers are degrading their security indicator — that’s a CRO disadvantage they may not realise they have.

What you need to know

Mixed content is when an HTTPS page loads resources over HTTP. Browsers handle this in two tiers:

Active mixed content is the high-risk category — <script>, <iframe>, <object>, <embed>, scripts in inline event handlers. Active content can modify the page, exfiltrate data, or hijack the user’s session. Modern browsers (Chrome since 2020, Firefox since 2019) block active mixed content entirely — the resource simply doesn’t load, and the page may break visibly.

Passive mixed content is the lower-risk category — <img>, <video>, <audio>, <source> for media. These can be observed and tampered with by someone on the network, but cannot directly modify the page. Browsers usually load passive mixed content but degrade the security indicator — the lock icon disappears or shows a warning. This is bad for trust and bad for CRO.

The audit reports both, with severity flags so the truly broken cases (active) are visible at the top:

• <script src="http://...">: blocked in modern browsers. The script doesn’t run; if the script is essential, the page is broken.
• <iframe src="http://...">: blocked. The iframe is empty or shows a browser error.
• <img src="http://...">: loads but degrades the indicator. Often the most common pattern in legacy WordPress sites.
• <link rel="stylesheet" href="http://...">: blocked. The CSS doesn’t load; styling breaks.
• url() in inline styles: loads but degrades. Common in WordPress themes that hard-code asset URLs in inline styles.
• <form action="http://...">: form submission is over HTTP. Submitted data is unencrypted on the wire — major security issue.

The fix is almost always the same: change the resource URL from http:// to https://. If the destination doesn’t support HTTPS, the resource needs replacing or removing. Protocol-relative URLs (//example.com/asset.png) are an old pattern that worked when sites were sometimes HTTPS and sometimes HTTP; they’re now redundant since everything is HTTPS, but they don’t cause mixed content (browsers resolve // to whatever protocol the page is using).

Modern Content Security Policy can also force resource upgrades — Content-Security-Policy: upgrade-insecure-requests instructs browsers to silently rewrite http:// references to https:// for the same host. This is a quick mitigation while you fix the underlying references, but it shouldn’t replace fixing the actual URLs.

Frequently asked questions

What’s the difference between active and passive mixed content?

Active mixed content (scripts, iframes, stylesheets, embeds) can modify the page or steal data; modern browsers block it entirely. Passive mixed content (images, video, audio) is less risky and is loaded with a degraded security indicator. Both should be fixed; active is more urgent.

Why does the lock icon disappear when I have mixed content?

Browsers downgrade the security indicator when any resource on the page loaded over HTTP. The page itself may be HTTPS, but if any sub-resource was unencrypted, the user’s experience of “this page is secure” is no longer accurate. Removing the indicator is the browser’s signal to the user that the security posture is degraded.

Are protocol-relative URLs (//example.com/...) safe?

Yes — they inherit the page’s protocol, so on an HTTPS page they resolve to HTTPS. They were the standard pattern when HTTPS adoption was uneven; they’re harmless but redundant in 2026. Don’t worry about removing them.

Can I just upgrade everything to HTTPS in code?

Yes — change every http:// to https:// and verify each destination supports HTTPS. Most modern services do. For ones that don’t, you’ll need to either find a different source or accept the mixed content (and its consequences).

What’s upgrade-insecure-requests?

A CSP directive that tells browsers to automatically rewrite http:// resource URLs to https:// for the same host. Useful as a transitional fix when you can’t easily update all the references. Not a substitute for fixing the references properly, since it only works for same-host resources.

Will mixed content affect my SEO ranking?

Indirectly. Mixed content degrades the security indicator, which affects user trust and click-through. Google’s HTTPS ranking signal is binary (HTTPS or not), so technically a page with mixed content is still HTTPS for ranking purposes. But the user-experience cost is real.

Why isn’t the audit fetching my image URLs to confirm they’re broken?

The audit reads the HTML and reports the http:// references it finds. It doesn’t fetch each resource to verify it’s actually loading or not loading. The presence of an HTTP reference is the issue — even if the resource happens to load fine over HTTP, browsers still degrade the security indicator because of it.

Can I have mixed content on subdomains?

Same rules apply per-subdomain. https://blog.example.com/page with an HTTP image is mixed content the same way https://example.com/page with an HTTP image is. The fix is the same: upgrade resource URLs to HTTPS.

Common problems

Problem: Cleared all HTTP references in the database but the audit still shows them.

The references might be coming from a theme, plugin, or CDN configuration rather than the database. Check templates for hard-coded HTTP URLs and CDN rules that might be rewriting URLs. WordPress’s “Better Search Replace” plugin is the standard tool for database-wide URL replacements.

Problem: Audit shows mixed content but Chrome doesn’t warn me.

Chrome’s mixed content blocker has different behaviour for first-party vs third-party resources, and for active vs passive content. Some passive mixed content is loaded silently without UI warnings. Run the audit anyway — silent mixed content is still degrading the security indicator.

Problem: Theme’s CSS file is loaded over HTTPS but inline styles reference HTTP images.

CSS url() in inline styles is a common gap because it’s not in the templated <link href> block — it’s generated per-page from custom fields, page-builder configurations, or content-block setup. Audit catches it; the fix is in the page-builder or theme configuration.

Problem: Third-party embedded content (iframes from old partners) loads over HTTP.

The destination doesn’t support HTTPS. Fix is one of: ask them to enable HTTPS (likely they’ve intended to and just haven’t), embed via a different mechanism, or remove the embed. Mixed-content active embeds are blocked in modern browsers, so the embed is already broken — removing it is honest.

Problem: Mixed content reports zero issues but the lock icon is still warning.

Run the audit on the actual rendered DOM (after JavaScript executes) rather than the source HTML. Some scripts inject HTTP-loaded resources after page load; the audit reads source HTML and won’t see those. Use browser dev tools’ Console to look for mixed content warnings at runtime.

Tips

• Active mixed content is broken in production — fix it first. Users are seeing missing scripts, broken iframes, or unstyled pages.
• Don’t use upgrade-insecure-requests as a permanent fix. It’s a transitional tool while you actually fix the references.
• Audit after every plugin or theme update. Updates sometimes regress URL handling silently.
• If you’re behind Cloudflare, their “Always Use HTTPS” and “Automatic HTTPS Rewrites” features can fix mixed content at the edge without code changes — useful for quick mitigation.
• Search-and-replace tools are the bulk fix for database-stored content. Test in staging first; some plugin databases have URL fields with non-obvious encoding that needs handling.

Related tools in this suite

The SSL Certificate Checker covers the cert-side of HTTPS posture; mixed content covers the content-side. Both need to be clean for a fully secure HTTPS implementation. The HTTP Headers Inspector covers security headers (HSTS, CSP, X-Frame-Options) that round out the security baseline.

What this looks like at scale

For a single page, the audit is fine. For a content site, mixed-content auditing should be automated — running on every page periodically, alerting on regressions. New content sometimes introduces HTTP references when authors paste in old image URLs or embed external resources. The WP Beacon Plugin audits mixed content across every page on every visit.

Take it further

If a content set has widespread mixed content from years of legacy editorial input, the right scope is a structured cleanup — database search-and-replace, plus auditing of templates and configuration. Talk through the audit and we can scope the work.