# Mixed Content Scanner: Find HTTP Resources on HTTPS Pages

> Scan an HTTPS page for mixed content: list scripts, styles, images, iframes and forms still loaded over http://, and see which ones browsers block.

Source: https://ssl.sh/tools/mixed-content-scanner/
Last updated: 2026-11-10

Find resources that an HTTPS page still loads over plain http:// and see which of them browsers block.

The mixed content scanner checks an HTTPS page for resources that are still loaded over `http://`. Enter the full page URL and press **Scan page**: you get a list of each insecure script, stylesheet, image, iframe or form target, with the active ones (which browsers block) counted separately.

## How to use it

1. Enter the page URL, for example `https://example.com/blog/`. Scan the pages that use different templates: home page, article, shop, checkout.
2. Press **Scan page**.
3. Fix each listed URL, then scan again.

## Active vs passive mixed content

- **Active** content can change the whole page: scripts, stylesheets, iframes, fonts, `fetch`/XHR requests. Browsers block it, so features break.
- **Passive** content is displayed but cannot change the page: images, audio, video. Current Chrome and Firefox try to load it over HTTPS automatically and block it if that fails; either way the page loses its secure state.

## How to fix it

1. Change hard-coded `http://` URLs in templates, themes and the database to `https://` (or to relative URLs for your own files).
2. For third-party resources, check that the provider supports HTTPS; replace those that do not.
3. As a safety net, send the header `Content-Security-Policy: upgrade-insecure-requests`.
4. Once the site is clean, enable [HSTS](https://ssl.sh/tools/hsts-checker/) so browsers never request plain HTTP again.

The scanner reads the page's HTML as served; it does not run JavaScript. For single-page apps, also check the browser console for [mixed content warnings](https://ssl.sh/errors/mixed-content-warning/).


## FAQ

**The page shows no padlock but the scanner finds nothing. Why?**

The insecure request is probably made by JavaScript after the page loads, or comes from a different page. Open the browser's developer console: it logs every mixed content warning with the exact URL.

**Is upgrade-insecure-requests enough?**

It tells browsers to fetch http:// sub-resources over HTTPS, which fixes most pages quickly. It only works if each resource is actually available over HTTPS; fix the URLs in your templates and database as the long-term solution.

**Are http:// links to other sites mixed content?**

No. Plain links (a href) that the user clicks are navigation, not sub-resources. Forms that submit to http:// are flagged because the submitted data would travel unencrypted.