What is mixed content, and what does this checker find?
Mixed content is what a browser means when it says a page is "not fully secure". The page itself arrived over https://, so the connection is encrypted, but something it loads — a script, a stylesheet, an image, a font, an iframe — is still being fetched over http://. Chrome calls those resources either *upgradable* or *blockable*: an insecure image is quietly rewritten to https:// and the padlock stays, an insecure script or stylesheet is refused outright, and the page loads without it. Either way the warning is the same, and the cause is almost always one hard-coded URL in a template nobody has looked at since the site moved to HTTPS.
This checker reads a page, collects every subresource it loads, and reports the ones still going over plain HTTP. It does not just look at `<script src>`: it reads `srcset` lists, `poster` attributes, `<link rel="stylesheet">`, `<link rel="preload">`, `<object data>` and — the one people miss — `url(...)` references inside inline `style` attributes and `<style>` blocks, which is where background images hide.
Then it asks the useful follow-up question. An `http://` URL in the markup is only half the story: if that address redirects to https://, or answers the same over either scheme, the fix is different from one that only serves plain HTTP. So each insecure resource is re-requested once, and the result says whether it upgrades, still serves over http://, or is gone.
How to find mixed content on a page
- Enter the full https:// address of the page. Use the exact URL a visitor lands on — a page reached by redirect can have a different set of subresources from the address typed in.
- Press Scan for mixed content. The page is fetched once, and the HTML is read for the tags that load something.
- Read the headline: the count of insecure subresources and how many of them are ones a browser blocks outright. Blocking resources are worse than the rest, because a blocked script does not run at all.
- Work down the table, worst first. Insecure scripts and stylesheets come first, then iframes, then everything else, with the tag and attribute that named each URL so you know where in the markup to look.
- Read the last column. `403 over http://` means the resource only exists insecurely and has to be moved or replaced; `308, but it redirects to https://` means the URL should simply be updated to https:// and the redirect dropped.
- Fix the template rather than the page, then re-run. If the same insecure URL appears on every page of a CMS, the fix belongs in the theme or the settings screen, so the next regeneration does not put it back.
Mixed content check limits and rules
| Item | Limit |
|---|---|
| Checked | `script src`, `img src`, `iframe src`, `embed src`, `audio`/`video` `src` and `poster`, `source src` and `srcset`, `track src`, `object data`, `link href` for stylesheets, icons, preloads and manifests, and `url(...)` inside inline styles and `<style>` blocks |
| Not checked | `form action` is reported as a resource but not re-requested, and anything injected by JavaScript after load is invisible, because nothing is rendered |
| Re-checked | Up to 12 insecure resources are requested again to see whether they still serve over http:// or upgrade to https:// |
| Protocol | Mixed content only counts on a page that is itself https://. An http:// page loading http:// things is a different problem, and the tool says so instead of listing them |
| Severity | Scripts, stylesheets and iframes are marked blocking; other tags are marked as passive, which is what Chrome calls them when it upgrades rather than blocks them |
| Request | One GET for the page, then at most 12 HEAD-or-GET requests for the insecure resources; no cookies or credentials of yours are sent |
| Rate limit | 40 scans per minute per visitor |
| Not included | Content security policy design, certificate validity, and the HSTS header — the header checker covers the policy and the SSL checker covers the certificate |
| Not verified | Switching the page to HTTPS and finding nothing here is not the same as being secure: a script served over https:// from a third party that later drops TLS is still a risk this cannot see |
When to use it
- Fixing the "not fully secure" warning on a site that was migrated to HTTPS years ago, where one old template still points an image or a widget script at http://.
- Confirming a fix worked after a CDN or theme change, without opening the developer console on every page.
- Finding the background image that only appears in a CSS inline style or a `<style>` block, which a search for `src="http://` never finds.
- Auditing a page that includes a third-party widget, to see exactly which of the widget's requests is still insecure and whether it upgrades.
- Checking a checkout or login page where a blocked script would break the page silently rather than merely showing a warning.
Is it private?
The scan runs on this site's server, because a page cannot read another origin's HTML to find its subresources. When you press the button, your browser sends the page address to this site's own endpoint, which fetches the page once, reads its markup, and re-requests up to 12 of the insecure addresses to see how they answer. The site you check sees requests from this server and never learns who asked. No cookies, credentials or browser details are forwarded, and neither the page nor the result is stored.
Frequently asked questions
Because the connection to the site is encrypted and something the page loads is not. The https:// part is what the padlock certifies; a single http:// image is enough for Chrome to downgrade the label to not fully secure, and an http:// script or stylesheet is blocked outright. The connection is genuinely encrypted — it is the page's contents that are not, which is why the warning is phrased that way rather than as an error.
Because the upgrade is a browser convenience, not a fix. Chrome and Firefox rewrite an insecure image, font or media request to https:// before sending it, so a passive resource usually works — as long as the host also serves it over https://. If it does not, the image silently disappears, and Safari, older browsers and non-browser clients never upgrade at all. The correct state is for the markup to name the https:// URL in the first place.
That the resource is one a browser refuses outright rather than rewriting: scripts, stylesheets and iframes. Chrome calls these blockable mixed content and will not load them over http://. The visible result is usually a page that mostly works with one feature missing — a broken layout, a form that does not submit, a widget that never appears — which is why a blocked script can go unnoticed for a long time.
Four things this scan cannot see: content injected by JavaScript after load, a subresource inside a cross-origin iframe, a resource loaded by a service worker, and a page reached through a redirect where the intermediate hop was http://. The last one is common and is fixed on the server rather than the page. For the first, open the browser's console — it names the exact URL it refused.
It is a useful safety net, not a substitute. `Content-Security-Policy: upgrade-insecure-requests` tells the browser to rewrite insecure subresources to https://, which covers the passive ones and is recommended alongside the fix. It does nothing for a resource that has no working https:// version — the request is upgraded and then fails — and it does not apply to clients that do not honour the directive. Fix the URLs, then add the directive so a missed one is not a warning.
It works, and it costs something: an extra round trip before the resource even starts loading, on every page view, plus the possibility that a browser refuses the insecure request before it ever gets to the redirect. The tool marks those rows clearly, and the fix is a one-line change in the markup — swap http:// for https:// and the redirect never happens.
Related tools
Written and maintained by Md. Nur Hossain Repon.