Mixed content: find the http:// files on your https page
Mixed content means a page loaded over https:// pulls in some of its files over plain http://. Browsers block insecure scripts, stylesheets and frames outright, which can silently break a booking widget, a form or the whole layout. For images, audio and video they either upgrade the request to https or show a warning. The fix is to load every file over https, after checking that the https version exists.
Blocked or just warned?
| File type | What browsers do | What you notice |
|---|---|---|
| Scripts, stylesheets, iframes | Block it | A widget that never loads, missing styling, an empty embed. Often no visible error. |
| Images, audio, video | Current browsers try the https address instead; older ones load it with a warning | Usually nothing, or a “Not secure” indicator; a broken image if no https version exists |
Ordinary links to http:// pages (<a href="http://…">) are not mixed content: the browser simply leaves your page when they are clicked.
Why it happens
- Images and files inserted into posts before the site moved to https, with their old address saved in the content
- A theme or template with a hard-coded
http://address - A third-party embed, widget or tracking snippet copied with
http:// - A setting such as the site address in your CMS still using http
How to find every http:// file
Your browser's developer tools show mixed content messages in the Console for the page you are on. Searching View Source for http:// also works, but it matches ordinary links too, so it is noisy.
The checker below lists every script, stylesheet, iframe, image and media file in the page's HTML that loads over http://, and separates the ones browsers block (to fix) from the ones they only warn about (to review). It checks every other link and file on the page for errors at the same time.
Limits: it reads the page's HTML, so files requested by your CSS or loaded later by JavaScript won't appear. Use the browser Console for those. It probes up to 100 links and files per check, your own files first.
How to fix it
- For each file, open its
https://address in a browser first. We don't check that the https version exists; if it doesn't, switching the URL will break the file instead of fixing it. - Change the address where it is written: the post content, the template, the theme setting, or the embed code.
- If a third party has no https version, replace the embed or host the file yourself.
- After a whole-site move to https, a database search-and-replace (with a backup first) fixes old content in bulk, and your CMS's site address should use https.
You may see the tag <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> suggested as a quick fix. It tells browsers to request every http file over https, which only helps if each of those files really exists at its https address. Treat it as a safety net, not a replacement for fixing the URLs.
How to confirm the fix
Run the check again until no insecure files are listed, then reload the page with the Console open and confirm no mixed content messages appear. Before launch, the website launch checklist covers the other things worth confirming on the same page.
Fixed this one? Before you send people to the page, run the full pre-publish check for everything else: indexing signals, link preview, broken links, alt text, structured data and HTTPS in one pass.