urltoolskit.org
URL utilities, in the browser
Say hi →

Mixed-content checker

blocked vs auto-upgraded vs warned · per resource type · parses HTML, or takes a URL list

"Not fully secure" in the address bar means something on the page loaded over plain HTTP — and browsers treat each resource type differently. A script is blocked outright and the page breaks; an image is silently upgraded; a form action gets a warning on submit. Paste your HTML to get each reference classified with the behaviour it will actually get.

Summary

Ready.

How to use

  1. Paste the page's HTML — view-source, or the rendered DOM from DevTools' Elements panel if resources are injected by script. A plain list of URLs works too.
  2. Set the Page URL if you have it. If it is http://, the tool says so: none of this is mixed content yet, but all of it becomes mixed content the moment you migrate.
  3. Read the Browser behaviour column. blocked is the one that breaks the page; upgraded works today but breaks if the resource has no HTTPS version; warned applies to form actions.
  4. Protocol-relative URLs (//host/path) are listed separately — not mixed content, but worth fixing.
  5. Copy the upgraded URL list, then check each one actually serves over HTTPS before shipping — an upgrade to a host with no certificate turns a working image into a blocked one.

What browsers do, resource by resource

Blocked outright — active content. Scripts, stylesheets, iframes, fonts, web workers, and fetch/XMLHttpRequest. These can change the page's behaviour, so an attacker who can modify them in transit owns the page. Browsers refuse to load them and log a console error. This is why a single http:// script tag takes a site down after an HTTPS migration.

Auto-upgraded — passive content. Images, video and audio are rewritten to https:// automatically by current browsers, and blocked if that fails. So an http:// image on a host with a valid certificate keeps working, and one on a host without a certificate now disappears where it used to load with a warning. Do not rely on the upgrade: fix the URL.

Warned on submit — form actions. A form on an HTTPS page posting to http:// sends its contents in clear text. Browsers show a warning, and some block the submission. On a login form this is a credential disclosure.

Not mixed content — navigation links. An <a href="http://…"> does not load anything into the page, so it is not mixed content. It is still a downgrade for whoever clicks it, and usually an unnecessary redirect.

Fixing it, and the one header that helps

The correct fix is to change the URLs. Use protocol-absolute https://, or root-relative paths (/assets/a.js) for your own resources, which inherit the page's scheme without the ambiguity of the //host form.

Where the references are spread across a database of user content or a legacy template you cannot edit, Content-Security-Policy: upgrade-insecure-requests tells the browser to rewrite every http:// subresource to https:// before requesting it — including the active content that would otherwise be blocked. It is a genuine migration aid, and it is not a fix: it depends on every referenced host supporting HTTPS, it does nothing for browsers that ignore CSP, and it hides the problem from your own audits. Use it to buy time while you correct the URLs.

block-all-mixed-content is the opposite lever — it blocks passive content too, instead of upgrading it, which turns silent breakage into loud breakage. Useful in a staging environment to find everything.

One thing this tool cannot see: resources injected at runtime by JavaScript, and URLs built by string concatenation. Paste the rendered DOM rather than the source to catch the first, and grep your codebase for http:// to catch the second.

FAQ

Can it check a live URL?

No — fetching a page cross-origin from a browser tab requires CORS permission the page will not have granted. Copy the source or the rendered DOM in. DevTools' Console also lists every mixed-content block on a page you load yourself, which is the fastest check for a page you can visit.

Why does DevTools show a mixed-content error my HTML does not explain?

Almost always a redirect or a nested resource: an https:// stylesheet that references an http:// font, or an https:// script that fetches over HTTP. Only the top level is visible in your markup — check the Network panel for the request that triggered it.

Are protocol-relative URLs still acceptable?

They work, and they are no longer recommended. Now that HTTPS is universal there is nothing to adapt to, and a //host URL is ambiguous the moment it is copied out of a page — into an email, a config file, a curl command — where there is no scheme to inherit.

Does it check CSS files?

It reads url() references inside <style> blocks and inline style attributes in what you paste. External stylesheets are separate files — paste their contents in as a second pass, or grep them for http://.