Mixed Content Checker

Scan an HTTPS page for mixed content — sub-resources still loaded over insecure http://. Enter a URL and this tool fetches the page and inspects its HTML for scripts, stylesheets, images, iframes and form actions pointing at http, then lists each one and whether browsers block it or merely warn. Mixed content is the usual reason an otherwise-HTTPS page loses its padlock or shows "not fully secure".

We fetch the page live from our server and scan its HTML for insecure sub-resources. Nothing is stored.

How to use the Mixed Content Checker

Enter an HTTPS URL and press Scan for mixed content. The tool fetches the page and reports:

  • Whether the page is clean or how many insecure resources it found.
  • Each insecure resource split into active (scripts, stylesheets, iframes, form posts — blocked by browsers) and passive (images, media — warned), with the exact http:// URL.
  • A note that the scan covers the initial HTML only — resources injected later by JavaScript are not visible to a server-side fetch.

The check only makes sense for an HTTPS page; if you enter an http URL the tool will say so, because the whole page is insecure rather than "mixed".

What mixed content is

Mixed content is when a page served over HTTPS loads some of its sub-resources — an image, a script, a stylesheet, an iframe — over plain http://. The main document is encrypted, but those individual resources are not, so the page is only partially secure. Browsers treat this as a real problem because an attacker on the network can tamper with the insecure parts even though the page itself arrived securely.

Browsers split mixed content into two severities, and they handle them very differently:

  • Active mixed content — resources that can change the whole page: <script>, <link> stylesheets, <iframe>, plugins, and form submissions. Because a tampered script could rewrite the entire page, browsers block these outright. The visible result is broken styling, dead JavaScript, or missing embedded content.
  • Passive mixed content — resources that only affect their own box: <img>, <audio>, <video>. The risk is smaller, so browsers load them but downgrade the security indicator, replacing the padlock with a "not fully secure" warning.

Either way, the fix is the same: every resource on an HTTPS page should also be requested over HTTPS. In practice that means changing hard-coded http:// URLs to https:// (or making them protocol-relative or root-relative so they inherit the page's scheme), and ensuring any third-party service you embed offers HTTPS. A single forgotten http image is enough to drop the padlock, which is why scanning is worthwhile after any migration to HTTPS.

Common use cases

  • Fixing a lost padlock — find the insecure resource that turned the address bar to "not fully secure".
  • After an HTTPS migration — catch hard-coded http URLs left behind when a site moved to HTTPS.
  • Debugging broken styling or scripts — discover active resources browsers silently blocked for being insecure.
  • Auditing third-party embeds — check that widgets, fonts and trackers you include all support HTTPS.
  • Pre-launch QA — confirm a new HTTPS site is fully secure before going live.

How to fix mixed content

Once the scan lists the offending URLs, the fixes are mechanical:

  • Change http:// to https://. The simplest fix, and usually all that is needed if the resource's host supports HTTPS (most CDNs and modern services do).
  • Use protocol-relative or root-relative URLs. Writing //cdn.example.com/x.js or /img/logo.png lets the resource inherit the page's scheme, so it stays HTTPS automatically.
  • Replace resources that have no HTTPS option. If a third party genuinely cannot serve a resource over HTTPS, you must self-host it or find an alternative — you cannot safely keep it.
  • Add a Content-Security-Policy upgrade. Content-Security-Policy: upgrade-insecure-requests tells the browser to automatically rewrite http sub-resource requests to https, a useful safety net while you clean up hard-coded URLs.
  • Re-scan after the fix. Because a single resource breaks the padlock, confirm the page comes back clean.

Note that this tool scans the server-rendered HTML. Resources injected later by JavaScript are not visible to a server-side fetch, so for a fully dynamic app also check the browser console, which logs every mixed-content event.

Frequently asked questions

What is mixed content?
Mixed content is when an HTTPS page loads some sub-resources, such as images, scripts or stylesheets, over insecure http. The page is only partially secure, so browsers either block the insecure parts or downgrade the padlock to a "not fully secure" warning.

Why did my HTTPS site lose its padlock?
Almost always because of one or more resources still loaded over http. A single insecure image, script or stylesheet is enough for the browser to drop the padlock. Scan the page to find which resource is the culprit.

What is the difference between active and passive mixed content?
Active mixed content (scripts, stylesheets, iframes, form posts) can alter the whole page, so browsers block it outright. Passive mixed content (images, audio, video) affects only itself, so browsers load it but show a security warning.

How do I fix mixed content?
Change each http:// resource URL to https://, or make it protocol-relative or root-relative so it inherits the page scheme. For resources with no HTTPS option, self-host them or replace them. Adding Content-Security-Policy: upgrade-insecure-requests helps as a safety net.

Does this catch resources added by JavaScript?
No. The scan inspects the server-rendered HTML, so resources injected later by client-side JavaScript are not visible to a server-side fetch. For dynamic apps, also check the browser console, which logs every mixed-content event.

Does this store the URLs I check?
No. Each scan runs live against the URL and nothing is logged or saved.