Mixed Content Scanner

1. Active vs. Passive Mixed Content

Per web.dev's mixed content guide, the distinction between active and passive content isn't arbitrary — it reflects real risk severity. Active content (JavaScript, CSS, iframes, XHR/fetch requests) can alter page behavior, steal data, or inject malicious code if intercepted on the network, so browsers block it outright. Passive content (images, video, audio) can still be tampered with — swapped for something misleading, for example — but can't execute code, which is why browsers flag rather than fully block it.

2. Modern Browser Mixed Content Blocking

All major browsers (Chrome, Firefox, Safari, Edge) block active mixed content by default and have done so for years — a blocked script or iframe typically fails silently from a visitor's perspective, which is exactly why mixed content bugs often go unnoticed until someone checks the browser console or a tool like this one flags it. Passive mixed content (images) usually still loads but strips the padlock indicator, which visitors are more likely to notice and lose trust over even without understanding the technical cause.

3. Enforcing upgrade-insecure-requests via Headers

A Content-Security-Policy directive called upgrade-insecure-requests tells the browser to automatically rewrite any HTTP subresource request to HTTPS before making it — a useful defensive backstop for legacy content with hardcoded http:// URLs, though it's not a substitute for actually fixing the underlying URLs (the upgrade can fail silently if the HTTPS version of the resource doesn't exist). Check whether this directive is already active with the HTTP Header Checker.

4. HTTPS Asset Handling via Nimbica Edge

Nimbica pre-renders WordPress content into static HTML served over HTTPS from edge locations — the delivery layer itself is secure by design. It doesn't retroactively fix hardcoded http:// references sitting inside your existing post content or database, which is a WordPress-side content issue that needs addressing at the source (see the FAQ above) regardless of hosting or delivery architecture.

5. How to Use This Scanner

1. Scan any HTTPS page and review the flagged HTTP resources, if any.
2. For each flagged resource, check whether an HTTPS version exists (most modern CDNs and image hosts support it) and update the reference.
3. If the issue is widespread across many pages, it likely traces back to database content rather than one-off page edits — consider a proper serialized-data-safe search-and-replace tool.
4. Re-scan key pages after fixing to confirm the browser padlock/warning is resolved.

6. Common Mistakes

• Using a naive find-and-replace on the WordPress database. WordPress stores some data as PHP serialized arrays with embedded string-length counts — a plain text find-and-replace on http:// → https:// can corrupt these if the string length changes, breaking widgets or settings. Use a tool built for WordPress's serialization format.
• Only checking the homepage. Mixed content often hides in older blog posts or rarely-visited pages that weren't touched during the original HTTPS migration.
• Assuming HTTPS redirect at the server level fixes everything. A server-level redirect handles the top-level page request; it doesn't rewrite hardcoded http:// references embedded inside the page's own HTML content.

7. Limitations

This scanner detects hardcoded http:// URLs visible in a page's raw HTML source — it doesn't execute JavaScript, so mixed content introduced dynamically by client-side scripts after page load won't be caught. It also checks one page per scan; a full-site audit means checking a representative sample across templates and older content.