Guide
Finding mixed content after moving a site to HTTPS
When a page is served over HTTPS but loads a script, an image or a frame over plain HTTP, the result is called mixed content. The unencrypted request can be read or changed by anyone on the network, and that makes the whole page less trustworthy. Browsers react by blocking the dangerous kinds and warning about the rest. The usual moment to meet the problem is right after moving a site to HTTPS, when old pages still point at http:// addresses. This scanner finds them in the HTML.
Active and passive content
Active content can take over the page: scripts, stylesheets, frames, fonts, fetch and XMLHttpRequest calls, and WebSockets. Modern browsers block it, which breaks the feature it provided. Passive content cannot change the page itself: images, audio and video. Current browsers upgrade it to HTTPS or load it with a reduced padlock, but it can still reveal what the visitor is viewing and be swapped for something misleading. A form that posts to an http:// address is also flagged, because the data it sends is unprotected.
A worked example
Press Sample to scan a small page. The page reports 10 insecure addresses: 5 blocked (active), 3 warnings (passive), 1 insecure link and 1 to check. The table lists each with its line, location, address and effect. Line 3, link href http://cdn.example.com/site.css, and line 4, script src http://cdn.example.com/app.js, are blocked. Line 7, an img src for logo.png, is a passive warning. Line 8, an iframe src, and line 9, a form action, are blocked. Line 10 is an a href to http://partner.example.com/, which is an insecure link and not mixed content. Line 5 is a style block with an @import of http://fonts.example.com/f.css, which is blocked, and two url() references, one to the same stylesheet and one to hero.jpg, which are passive warnings. Line 11 contains a script string literal ws://live.example.com/socket, marked to check, because a WebSocket over ws:// is blocked on an HTTPS page but the string might not be used.
Where references hide
Beyond src and href, insecure addresses appear in srcset lists, poster attributes on video, data attributes of objects, inline style attributes, CSS @import and url() in style blocks, and strings inside scripts. Content management systems also store absolute http:// addresses in the database, in posts and theme settings. The scanner reads attributes and script strings in the markup you paste, so paste the rendered HTML (view-source or the saved page) and not only a template.
Fixing
Replace the address with https:// after checking that the resource is served that way. For your own resources, use relative or root-relative paths so the scheme follows the page. Where a third party offers no HTTPS version, host a copy yourself or drop the dependency. As a safety net, the upgrade-insecure-requests directive of a Content-Security-Policy asks browsers to try HTTPS for all sub-resources, but it hides the problem rather than fixing the addresses.
Limits
The scan reads text. It cannot see resources your JavaScript builds at run time, requests triggered by third-party scripts, or content loaded after the user interacts. For those, open the page with the browser developer console, which lists mixed content warnings, or use a crawler. The page does not load addresses or follow redirects.
Related tools
- HSTS Header Generator enforces HTTPS for all future visits.
- CSP Generator and Evaluator can add upgrade-insecure-requests as a safety net.
- SRI Hash Generator pins the third-party files you keep.
- Security Headers Generator and Auditor checks the rest of the response.
Checked against the current version of the Mixed Content Scanner on .