Mixed Content Checker

Server assisted New Internet Security & Privacy

Enter the address of an HTTPS page and the Mutqan server downloads its HTML once, or paste the HTML yourself. The page is read as text only — nothing on it runs or loads — and every http:// reference is listed and classified as the W3C Mixed Content specification does: active content that browsers block, or passive content they upgrade to https://, with upgrade-insecure-requests detected when the page sets it. Form actions and meta refresh targets that lead to http:// are listed apart: they are navigations, which browsers do not block as mixed content.

Privacy: The Mutqan server sends the small, fixed test requests described on this page to the host you name, and nothing is stored. Use it only against systems you are authorised to test.

What is mixed content and why do browsers block it?

Mixed content is a resource that an https:// page loads over plain http://. Anyone on the network path can read or replace that resource, so a single http:// script would hand control of the encrypted page to an attacker; the W3C Mixed Content specification therefore has browsers block scripts, stylesheets, frames and similar "blockable" content, and request images, audio and video over https:// instead.

How to use Mixed Content Checker

  1. Enter the https:// address of the page, or paste its HTML (view-source, a saved file or a template); with pasted HTML, add the page URL too so relative links resolve.
  2. Press Check page.
  3. Fix the rows marked "Blocked by browsers" first: those resources do not load at all on the HTTPS page.
  4. Then move the passive references and form actions to https://, and run the check again until the list is empty.

Mixed Content Checker features

  • Lists every http:// resource an https:// page references: scripts, stylesheets, images and srcset candidates, frames, audio and video, fonts, plugin objects, form actions, inline CSS url() values and meta refresh targets
  • Sorts each subresource into active (blockable) or passive (upgradeable) content as the W3C Mixed Content specification defines, lists form actions and meta refresh targets apart as navigations, and says what a current browser does with each
  • Detects upgrade-insecure-requests in the Content-Security-Policy header or in a meta tag, the directive that makes browsers rewrite subresource URLs and form submissions to https:// — pasted HTML can show only the meta tag, so there a missing tag reads as Unknown
  • Resolves relative URLs against the page address and the first base element, so a base href that points to http:// is caught, and protocol-relative URLs (//host/path) take the scheme of the page as they do in a browser
  • Works on a live page fetched by the Mutqan server or on HTML you paste — a template, a saved page, or a page behind a login
  • Reads the HTML as text only: nothing on the page is executed or loaded, either by the Mutqan server or by your browser
  • Counts a repeated reference once, with the number of times it appears, and exports the list as CSV

Inputs and outputs

Inputs

  • Page URL — the https:// page to check (a bare host is read as https://). The Mutqan server makes one GET request with a fixed header set that identifies the Mutqan relay (User-Agent MutqanTools-Relay/1.0), and follows up to 5 redirects.
  • Pasted HTML — the page source, as an alternative to fetching; when present nothing is sent, and the page URL (if given) is used only to resolve relative links.

Outputs

  • Summary — whether the page is HTTPS, how many subresource URLs were read, how many insecure references are active (blockable) and passive (upgradeable), how many forms and meta refreshes lead to http://, and whether upgrade-insecure-requests is set (Unknown for pasted HTML without the meta tag).
  • Insecure references — one row per distinct http:// URL: its type, the element and attribute it sits in, what browsers do with it and how many times it appears.
  • What this means — the consequence of each kind of finding and what to change.
  • Fetch details — for a fetched page: the requested and final URL, status, Content-Type, how much HTML was read, the resolved address and the fetch time.

Mixed Content Checker example

A shop page with six insecure references

Input:

Page URL: https://www.example.com/shop
<link rel="stylesheet" href="http://cdn.example.net/css/theme.css">
<script src="http://widgets.example.org/chat.js"></script>
<img src="http://images.example.net/banner.jpg" alt="Sale">
<video src="http://media.example.net/intro.mp4" poster="//media.example.net/intro.jpg"></video>
<iframe src="http://maps.example.org/embed?q=riyadh"></iframe>
<form action="http://www.example.com/subscribe" method="post">

Output:

Page HTTPS · Subresource URLs read 7 · Active (blockable) 3 · Passive (upgradeable) 2 · Forms and redirects 1 · upgrade-insecure-requests Unknown — response headers not read
Stylesheet · link[href] · http://cdn.example.net/css/theme.css · Blocked by browsers
Script · script[src] · http://widgets.example.org/chat.js · Blocked by browsers
Frame · iframe[src] · http://maps.example.org/embed?q=riyadh · Blocked by browsers
Image · img[src] · http://images.example.net/banner.jpg · Upgraded to https:// by current browsers; dropped if that fails
Audio or video · video[src] · http://media.example.net/intro.mp4 · Upgraded to https:// by current browsers; dropped if that fails
Form action · form[action] · http://www.example.com/subscribe · Browsers warn before sending the form
(the //media.example.net poster is protocol-relative and therefore secure)

How to read the Mixed Content Checker results

"Blocked by browsers" rows are already broken for every visitor on a current browser: the script, stylesheet, font or frame does not load, so layout, features or embeds that depend on it fail silently.

Passive rows usually still display, because current browsers upgrade images, audio and video to https:// — but only if the same file exists over HTTPS. Where it does not, the image or video is missing; in older browsers the page loses its secure padlock.

An empty list means no http:// reference was found in the HTML that was read — not that the page is free of mixed content. Scripts can still insert http:// URLs after the page loads.

If the page itself is reported as HTTP, the result is not about mixed content at all: the whole page is unencrypted, and moving it to HTTPS comes first.

Form and meta refresh rows are not blocked. After the browser's warning the form still sends what the visitor typed unencrypted, and a meta refresh takes the visitor to an unencrypted page, so both belong on https:// as well.

When to use Mixed Content Checker

  • Migrating a site from HTTP to HTTPS and finding the hard-coded http:// links left in templates and content.
  • Investigating why a stylesheet, font or embedded map does not appear on the HTTPS version of a page.
  • Reviewing CMS content or e-mail-to-web exports that paste absolute http:// image URLs into articles.
  • Checking a page before turning on upgrade-insecure-requests or HSTS, so every resource is known to work over HTTPS.

Troubleshooting

  • The result is empty although the browser console shows Mixed Content warnings: those resources are added by JavaScript after load, or referenced inside an external CSS file. Search the scripts and stylesheets for "http://".
  • "The response is not an HTML page": the URL points to a file, an API or a redirect target that is not HTML. Enter the address of the page itself.
  • Relative links in pasted HTML resolve to the wrong host: enter the page URL as well, or check that the HTML contains its base element.
  • The page requires sign-in, or blocks automated requests: open it in your browser, view the source and paste the HTML instead of the URL.

Frequently asked questions about Mixed Content Checker

What is the difference between active and passive mixed content?

Active content can change or read the page — scripts, stylesheets, frames, fonts and plugin objects — and browsers block it outright when it arrives over http:// on an HTTPS page. Passive content is images, audio and video: current browsers request it over https:// instead, and if the file is not available over HTTPS it does not appear.

Why did the padlock disappear although my site uses HTTPS?

Usually because the page still loads something over http://, such as an old image in an article or an external widget. Check the page here to see the responsible URL, then change it to https:// after making sure the file exists over HTTPS.

Does the check load the resources or run the page's scripts?

No. The Mutqan server fetches the HTML only and returns it to your browser, where it is read as text. No script runs and none of the listed resources is requested, so the check never contacts the third-party hosts the page references.

The list is empty but the browser console shows Mixed Content warnings. Why?

Those resources are added by JavaScript after the page loads, or referenced from external CSS files, and the check reads only the page's HTML. Search the scripts and stylesheets for "http://", or watch the Console tab of the developer tools.

Is adding upgrade-insecure-requests enough?

It makes browsers request every http:// subresource, and send every form, over https:// automatically, but it does not create the secure copy of the file: a resource that is not available over HTTPS then fails to load. It is a safety net during a migration; the lasting fix is to write the URLs as https:// or relative.

Technical notes

Classification follows the W3C Mixed Content specification: scripts, stylesheets, frames, fonts, plugin objects and fetch-like preloads are "blockable" (active) content that browsers refuse to load over http:// on an https:// page; images, audio and video are "upgradeable" (passive) content that Mixed Content Level 2 tells browsers to request over https:// instead. Form actions and meta refresh targets are navigations, which the specification leaves out of mixed-content blocking; for a form that submits to http:// it lets the browser warn or block, and current browsers warn.

URLs are resolved as the WHATWG URL Standard and the HTML Standard require: against the page URL, or the first base element when the page has one; a protocol-relative URL inherits the https scheme of the page; data:, blob:, about: and javascript: URLs are ignored.

upgrade-insecure-requests (W3C Upgrade Insecure Requests) is read from the Content-Security-Policy response header of a fetched page and from a meta http-equiv="Content-Security-Policy" tag in the HTML; pasted HTML has no response header, so without the meta tag the answer there is Unknown. With the directive, browsers rewrite every subresource URL and every form submission to https:// before the request, and a navigation when it stays on the page's own host, so the list shows what must exist over HTTPS rather than what is blocked.

The HTML is scanned with a tolerant tag scanner, not a browser: it reads attributes, srcset candidates, inline style attributes and style blocks, and stops at 5,000 tags or 2 MB of text. A fetched page is read up to the 512 KiB the Mutqan server returns.

Limitations and methodology

Only the HTML that was read is checked. Resources injected by JavaScript, referenced inside external stylesheets or loaded by fetch/XHR calls, and the content of frames, are outside the check.

The page is fetched once by the Mutqan server on Cloudflare's network, without cookies or sign-in; a page that differs by user, device or region may reference other resources for real visitors. Only the first 512 KiB of HTML is read.

What a browser does with passive content depends on its version: the table describes current browsers that implement Mixed Content Level 2 upgrading; older browsers load passive content over http:// with a warning.

Security and privacy

In URL mode the URL goes to the Mutqan server, which downloads the page once and returns its HTML to your browser for the check; nothing is stored. In paste mode the HTML never leaves your browser.

The HTML is treated as text: its scripts never run and none of the resources it lists are requested, so checking a page does not contact the third-party hosts it references.

References

  • Mixed ContentW3CDefines mixed content, which requests browsers block (blockable) and which they upgrade to https:// (upgradeable).
  • Mixed content — MDNMDN Web Docs (Mozilla)How browsers treat each kind of mixed content today, with the console messages and the ways to fix it.
  • Upgrade Insecure RequestsW3CThe CSP directive upgrade-insecure-requests, which makes a browser rewrite a page's http:// requests to https:// before sending them.