The idea
A page is not one thing. It is a document plus everything it pulls in: images, fonts, stylesheets, scripts, videos, embeds.
When you switch to HTTPS, the document arrives encrypted. But each of those extra parts is a separate request, and each one has its own address. If any of them still start with http://, that part travels in the open.
So the padlock is telling you about the document. It is not a promise about everything on the page. Mixed content is the gap between those two things.
Why it actually matters
Anything sent over plain HTTP can be read by whoever is in the middle, and more importantly it can be changed.
Reading a logo is not interesting. Changing a script is. An insecure script has the same power over your page as a secure one, which means anyone able to tamper with it in transit can rewrite your checkout, add a form, or quietly read what a customer types. That is why browsers treat insecure scripts and stylesheets far more harshly than an insecure image.
This is the same category of risk as web skimming, just with the door left open rather than kicked in.
What you will actually see
You rarely get a clear error saying "mixed content". You get symptoms.
- →The padlock changes or disappears. The address bar stops looking reassuring, and customers notice that even when they cannot explain it.
- →The resource just does not load. Browsers block insecure scripts and stylesheets outright, so a slider stops working or the layout falls apart, with nothing obviously wrong in the page itself.
- →It works for you and not for someone else. Caching and browser differences make this maddening to chase by eye.
- →Nothing at all is visibly wrong. An insecure image loads happily and silently downgrades the page.
Where it comes from
Almost always from http:// URLs written down somewhere and forgotten.
Typical culprits are old blog posts and product descriptions with pasted image URLs, theme settings holding a logo or background address, plugin options, and third-party embeds that were added years ago. The site was built on HTTP, the certificate went on later, and none of those old addresses updated themselves.
It is worth saying plainly: getting a certificate does not fix this. The certificate secures the connection. It has no opinion about what your content asks the browser to go and fetch.
Fixing it properly
The fix is to find those URLs and change them. The care is in how you do the finding and changing.
On WordPress specifically, do not run a plain SQL find and replace across the database. WordPress stores a lot of settings as serialized PHP, and serialized data records the length of every string it contains. Swap http:// for https:// and every one of those strings gets one character longer while the recorded length stays the same. The data is now corrupt, and it tends to fail silently: theme options reset, widgets vanish, settings revert.
Use a search and replace tool that understands PHP serialization, so it rewrites the lengths as it goes. Back up first either way.
One more thing to skip. Protocol-relative URLs, the ones starting //example.com, were a common workaround for this and are now legacy. They are no longer recommended. Write the full https:// address and be done.
Run a free check to see whether your pages are loading anything insecurely.
We have step by step instructions for every major platform, including the ones that will not let you.
See how to fix mixed content on your platform