Which mixed content does a browser block outright?

Active content: scripts, stylesheets, iframes, and fonts. Those can rewrite the page, so browsers refuse to load them over http:// on an HTTPS page, which is why the visible symptom is often a broken layout or a dead feature rather than a warning. Images and media are usually upgraded or shown with the padlock removed.

Why does this report WARN rather than FAIL?

Because the page is served over HTTPS and the transport itself is sound, while the insecure references are individually fixable. It still belongs on the fix list: each one is a request an attacker on the same network can tamper with, and the missing padlock is what visitors notice.

The reference comes from a plugin or theme. How is it found?

The report names the insecure URLs it found in the served HTML, which usually identifies the component by its path. On a CMS the common sources are a hardcoded http:// in a widget, an old site URL setting, and content pasted years ago with absolute links, in that order.

Does upgrade-insecure-requests fix it?

It hides it, and it is a reasonable stopgap. The directive makes the browser retry insecure subresources over HTTPS, so the page works and the padlock returns, but any host that has no HTTPS version fails to load instead. Rewriting the references is the fix that survives.

← All security check guides

Check an HTTPS page for mixed content

Mixed content is when a page served over HTTPS still pulls in scripts, images, or styles over plain http://. Those requests are unencrypted, and browsers either block them outright or drop the padlock, so the page ends up both less secure and looking broken.

What it costs

On CheckWeb this is a weight-1 check on the Security axis, lighter than the gates around it, because a single insecure image is a smaller risk than a broken certificate. Its real cost is visible to every visitor: modern browsers block mixed active content like scripts, and downgrade the padlock, so the page loses protection and looks insecure at the same time.

How it looks in the report

Under the Security axis, "Mixed content (HTTP on HTTPS)". A clean page shows PASS with "No insecure (http://) subresources". A fail lists the insecure resources it found.

Example

Mixed content (HTTP on HTTPS)

No insecure (http://) subresources

PASS

Present vs clean

Present

A page loads http:// assets. Active ones (scripts, iframes) get blocked by the browser; passive ones (images) drop the padlock.

Clean

Every subresource loads over https:// or a protocol-relative path.

How to fix it

Change http:// asset URLs to https:// (or protocol-relative //) wherever the page controls them.
For third-party assets, confirm the provider serves HTTPS, then update the URL.
During a migration, a Content-Security-Policy with `upgrade-insecure-requests` can auto-upgrade requests while URLs are cleaned up (CSP guide).
Verify: re-scan.

Check a page for mixed content

Paste a URL to see whether an HTTPS page loads any insecure http:// resources, and which ones. Fix, re-scan, confirm.

Check my website

FAQ

Which mixed content does a browser block outright?: Active content: scripts, stylesheets, iframes, and fonts. Those can rewrite the page, so browsers refuse to load them over http:// on an HTTPS page, which is why the visible symptom is often a broken layout or a dead feature rather than a warning. Images and media are usually upgraded or shown with the padlock removed.
Why does this report WARN rather than FAIL?: Because the page is served over HTTPS and the transport itself is sound, while the insecure references are individually fixable. It still belongs on the fix list: each one is a request an attacker on the same network can tamper with, and the missing padlock is what visitors notice.
The reference comes from a plugin or theme. How is it found?: The report names the insecure URLs it found in the served HTML, which usually identifies the component by its path. On a CMS the common sources are a hardcoded http:// in a widget, an old site URL setting, and content pasted years ago with absolute links, in that order.
Does upgrade-insecure-requests fix it?: It hides it, and it is a reasonable stopgap. The directive makes the browser retry insecure subresources over HTTPS, so the page works and the padlock returns, but any host that has no HTTPS version fails to load instead. Rewriting the references is the fix that survives.

Related checks

Browse recent public reports →