Mixed Content Checker

Find insecure http resources loaded on an HTTPS page.

The Mixed Content Checker inspects whether an HTTPS page loads insecure resources over plain http:// — images, scripts, stylesheets and more. Enter a URL and the server fetches the page's HTML, then scans the img, script, link, iframe, video, audio and source tags for any plaintext HTTP resource, listing each one by tag, address and total count.

Mixed content breaks the padlock icon, and modern browsers outright block active content such as scripts and stylesheets, which can break your layout or functionality. Run this tool before and after a deploy to make sure no plaintext links remain. A count of zero is healthy; any insecure resource is flagged as dangerous.

URL to checke.g. https://example.com (an HTTPS page)

Why mixed content is dangerous

Even when the page body is delivered encrypted over HTTPS, any resource it pulls in over plain HTTP is exposed to interception and tampering. An attacker who swaps out a script in transit can compromise the whole page, so browsers treat mixed content as a security weakness.

Active content (script, iframe, link[stylesheet]) is usually blocked outright.
Passive content (img, video, audio) is blocked or shown with a warning.
The padlock icon changes to "not secure" or a partially secure state.

How to fix it

The simplest fix is to change every resource URL to https://, or to use protocol-relative (//example.com/...) or root-relative (/assets/...) paths. If an external host has no HTTPS support, move the resource onto your own server or switch to a host that does. For bulk migration you can apply a temporary upgrade with the Content-Security-Policy: upgrade-insecure-requests header. Use the security headers checker to confirm that CSP and your other security headers actually landed in the response.

Frequently asked questions

What happens if I enter an HTTP page?

Mixed content only matters on HTTPS pages. If your URL ultimately resolves to HTTP, the tool reports 'not an HTTPS page' and skips the scan. Move the site to HTTPS first.

Does it catch dynamically injected resources?

This tool analyzes only the initial HTML the server returns. http:// resources injected at runtime by JavaScript may not appear in static analysis, so also check the mixed-content warnings in your browser's DevTools console.

Can the count differ from what's actually blocked?

Yes. Browsers treat active and passive content differently and auto-upgrade some requests to HTTPS. This tool lists every resource written as plaintext http:// in the HTML, so it shows the full set of potential risks.

Is the URL I enter stored externally?

Results are briefly cached for 60 seconds to reduce load — nothing is stored permanently or sent to third parties. The server fetches only the target page after passing safety (SSRF) validation.

Is there a way to fix mixed content all at once?

Adding a Content-Security-Policy: upgrade-insecure-requests header tells the browser to automatically promote http:// resource requests on the page to https://. That is a stopgap, though — the real fix is to correct the resource URLs in your source to https.

Related tools

Web Security →

CSP Generator

Build a Content-Security-Policy header for your site's resources.

SRI Hash Generator

Generate Subresource Integrity hashes for external JS/CSS.

Password Policy Generator

Generate a password policy and its rules for your service.

Security Headers Checker

Check and grade security headers like HSTS, CSP and X-Frame-Options.

Cookie Security Check

Check Secure, HttpOnly and SameSite flags on response cookies.

security.txt Checker

Check for /.well-known/security.txt and its required fields.