Mixed content: why the padlock disappears and how to find the cause
One image loaded over plain HTTP downgrades a whole secure page. How mixed content happens, how to find the file in two minutes, and how to stop it coming back.
The short answer
Mixed content is a page that is itself loaded over HTTPS but pulls in at least one file over plain HTTP. The browser cannot vouch for the whole page anymore, so it removes the padlock, shows a warning, and for scripts, blocks the file entirely. One old image link is enough.
It is one of the most common findings in scans of small business websites and one of the fastest to fix once you know where to look.
How it happens
Almost always the same way. Years ago, before the site had HTTPS, someone pasted a full address into a page: an image from the old media library, an embed from a partner, a tracking script. The site later moved to HTTPS, most links were relative and came along, but the pasted absolute links still start with http://. The page is secure; the pasted file is not.
Other sources: a plugin or theme that hardcodes http:// addresses, an embed code copied from a third party, or a content system that stores full URLs and was never updated after the switch.
Find it in two minutes
- Open the page with the warning and open your browser’s developer tools.
- Look at the console. It lists every mixed content item with the exact address of the file and whether it was blocked or only flagged.
- Note the file and the page. For images, that is usually one pasted link in the content. For scripts, it is usually a template or an embed.
- Search the whole site for “http://” in content and templates. Where there is one old link, there are more.
Fix it
| Situation | Fix |
|---|---|
| The file is available over https | Change the link from http:// to https:// |
| The file is your own, from an old location | Upload it to your current site and link it relatively |
| The file is a third-party script that has no https version | Remove it. A script that cannot be served securely should not run on your page |
| The links are stored in a content system | Run a search and replace on the stored content, then check the pages |
| A plugin or theme injects the link | Update it, configure it, or replace it |
Stop it coming back
Two more habits close the loop: a check for http:// in content before publishing, which most content systems and build steps can do, and a regular scan that reports mixed content per page. With those in place, the padlock stays.
What this means for you
If any page of your site shows a warning, the console tells you which file within a minute, and the fix is a link change. Do the site-wide search while you are at it, add the upgrade rule, and the problem is gone for good. If you would rather not open developer tools, a quick scan lists every affected page and file in one report.
Frequently asked questions
Why does only one page show the warning?
Because only that page contains the insecure file. Typically an image or embed added by hand with a full http:// address. The rest of the site uses relative links or https, so only the page with the old link is affected.
Is mixed content dangerous, or just a warning?
Both. Insecure images are mostly a trust and appearance problem. Insecure scripts are a real risk, because a script loaded over plain HTTP can be replaced on the way and then runs with full access to your page. Browsers block insecure scripts outright and warn for images; both need fixing.
Can the server fix this automatically?
Partly. A Content Security Policy directive called upgrade-insecure-requests tells the browser to request every http:// resource over https:// instead, which works when the file is available over https. It is a good safety net. It does not fix files that only exist over http, and it does not clean up the content.
We fixed it and it came back. Why?
Someone pasted another old link, or a plugin or embed code injected one. Add a check for http:// links to your content workflow, keep the upgrade rule as a net, and look at what changed on the page since the last clean scan.
Sources
- MDN Web Docs: Mixed content (accessed 2026-09-11)
- MDN Web Docs: Content Security Policy (accessed 2026-09-11)