What browsers actually do now
This is where most guides are out of date. They describe a world of yellow warning triangles and silently downgraded pages. That behaviour changed with Chrome 80.
Images, audio and video requested over HTTP are automatically upgraded to HTTPS. If the upgrade succeeds, the file loads and nobody notices. If the upgrade fails, the file is not loaded. It is not quietly fetched over HTTP instead.
Everything else is blocked outright with no upgrade attempt at all. That covers scripts, iframes, stylesheets, fonts, and background requests made with fetch or XHR.
So the modern rule is short. Passive media gets one chance to be upgraded. Active content gets none.
Why you will probably never see a warning
This is the practical problem, and it catches out experienced developers.
There is no banner. There is no popup. The detail lives in the browser console, which visitors never open and most owners rarely check.
What you actually get is a broken image on one product page, or a live chat widget that stopped appearing three weeks ago, or a font that reverted to a system default. Symptoms that look like unrelated small bugs.
By the time somebody reports it, it has usually been happening for a while. That is why it is worth checking deliberately rather than waiting to be told.
The wording you may still see
Chrome does surface mixed content in a couple of places.
- →Your connection is not fully secure appears in the site information panel when a page has loaded insecure content.
- →The information you're about to submit is not secure is the separate warning shown when a form on a secure page posts to an insecure address. This one visitors do see, and it appears right at the moment they are trying to buy something.
- →The address bar label may change. Depending on what was loaded, Chrome may stop treating the page as fully secure.
- →The console has the detail. It names each blocked or upgraded request, which is the only place you get the actual file paths.
If it is your site: how to fix it
The work is finding the insecure addresses, not repairing them. Once you can see them the fix is mechanical.
- 1.Open the browser console on a page that looks wrong. Blocked and upgraded requests are listed there with their full URLs. Start with a product page and your homepage.
- 2.Search your database for hardcoded http:// addresses. This is the usual culprit. Content editors paste image URLs, and old posts keep the address the site had before it moved to HTTPS.
- 3.Run a proper search and replace. On WordPress use a tool that handles serialised data, because a plain SQL replace will corrupt widget and plugin settings. Take a backup first.
- 4.Check your theme and template files. Hardcoded asset paths in a theme survive database migrations and keep reappearing.
- 5.Check third-party embeds. Old chat widgets, tracking pixels, map embeds and payment scripts sometimes still use HTTP addresses. Some have HTTPS equivalents. Some need replacing.
- 6.Re-check afterwards. Run a free check and click through your key pages with the console open. Our guide to SSL on WordPress covers the platform specifics.
Why blocking is the right behaviour
It can feel heavy handed when a single old image breaks a page. It is not.
An insecure script on a secure page can be replaced in transit by anyone able to see the traffic. Once that happens the attacker is running code inside your page, with access to everything on it, including whatever a customer is typing into a form.
Encrypting the page and then loading executable content over an open connection undoes the encryption entirely. Browsers block it because the alternative is a false sense of security, which is worse than none.
The mixed content and TLS glossary entries go into the mechanics if you want them.
Frequently asked questions
Is mixed content dangerous for me as a visitor?
The browser has already dealt with it. Insecure scripts and frames are blocked, and insecure media is either upgraded or dropped. What you are left with is a page that may look broken rather than a page that is unsafe. Do not enter payment details if a checkout page is visibly misbehaving.
Why do my images not show since I moved to HTTPS?
Because the image addresses are still written as http:// in your content, and the automatic upgrade to HTTPS is failing for those files. Search your database for hardcoded http:// URLs, which is where they almost always live.
Does mixed content make my site show as Not secure?
It can. Chrome may stop treating the page as fully secure, and the site information panel says "Your connection is not fully secure". A form posting to an insecure address also triggers a visible warning to the customer at the worst possible moment.
How do I find mixed content without checking every page?
Start with the console on your highest traffic pages, then search the database directly for http:// occurrences. Between those two you will catch nearly all of it. Template files are the third place to look, since they survive content changes.
Can I just tell the browser to allow it?
No, and you would not want to. The blocking is not configurable by site owners, because the whole point is that an attacker could otherwise substitute the insecure resource. The only correct fix is to serve everything over HTTPS.