What this tool does
Paste the source of a page and this mixed content checker lists every http:// resource in it,
separating the ones a browser refuses outright from the ones it quietly rewrites. Each item comes
with the tag, the attribute, the approximate line and the exact https:// replacement, plus the
list of distinct hosts — which is the list of vendors you actually have to talk to.
It reads markup only. Nothing is fetched, nothing is uploaded, and the tool never sees the page your source came from.
Active and passive, and why the difference matters
An HTTPS page that loads a subresource over plain HTTP has, in the strict sense, no security at all: anyone on the network path can rewrite that resource in transit. Browsers treat the risk in two tiers depending on what the resource can do once it arrives.
Active content can rewrite the document: scripts, stylesheets, iframes, plugin objects, form submissions, and anything loaded by fetch or XHR. A tampered stylesheet can hide the real submit button and show a fake one; a tampered script owns the page. Chrome blocks all of it, and the failure is quiet — the console logs it and the feature simply does not exist for your visitors.
Passive content — images, video, audio, favicons — cannot execute, so the worst case is a misleading picture rather than a hijacked page. Modern Chrome tries the HTTPS version first and uses it if the host answers. If the host does not support TLS, the asset is dropped and you get an image-shaped hole.
The practical consequence: an active item is an outage you have not noticed yet, and a passive item is a padlock you have already lost. The strict toggle in the tool treats both as errors, which is the right setting when you are checking a template you are about to ship.
Protocol-relative URLs are a dead pattern
Writing //cdn.example.net/app.js was the standard trick when a site was reachable on both
schemes: the browser inherited whichever one the page was on. That situation no longer exists.
Everything is HTTPS, the inheritance buys nothing, and the form has two real costs — the file
breaks when opened from disk, and nobody reading the template can tell which scheme is in play. The
checker counts these separately rather than reporting them as insecure, because on a live HTTPS
page they resolve correctly today. Write the scheme out anyway.
The order to fix them in
Start with the hosts, not the lines. One vendor domain usually explains a dozen findings, and if that vendor serves HTTPS the fix is a single search and replace. Where a host has no TLS at all, you are choosing between dropping the dependency and proxying it through your own domain — and proxying somebody else's script is inheriting their security, so prefer dropping it.
Hard-coded addresses in a CMS are next: old post bodies, theme options, email templates and anything a marketing team pasted. Those outlive every deployment and are the reason a site that was clean at launch is not clean a year later.
Finally, add upgrade-insecure-requests as a backstop for what you missed, then keep checking
templates as you edit them. If you are also cleaning up how the old scheme is served, the
htaccess redirect generator writes the HTTP-to-HTTPS rule, and the
meta tag generator is the place to make sure the canonical you emit points
at the secure URL too.