Guide Errors & Troubleshooting

How to fix a mixed content console error

Your page is secure but one thing on it is not, and the browser is refusing to pretend otherwise — here is how to find that one thing.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

A mixed content error appears in the browser's developer console, typically reading something close to: "Mixed Content: The page at 'https://yourdomain.com/' was loaded over HTTPS, but requested an insecure resource 'http://yourdomain.com/image.jpg'. This request has been blocked; the content must be served over HTTPS." It means a page loaded securely is trying to pull in something — an image, a script, a stylesheet — over plain, unencrypted HTTP instead.

Browsers treat this as a security concern because a single insecure resource on an otherwise secure page can be used to undermine that security, so modern browsers actively block certain kinds of mixed content rather than merely warning about it.

Active versus passive: why some things are blocked and others aren't

Not every mixed content warning behaves the same way, and the distinction matters for how urgently to treat it.

Type	Examples	Browser behaviour
Active content	Scripts, stylesheets, iframes, fonts	Blocked outright. The resource does not load at all, and this is the type most likely to visibly break something.
Passive content	Images, video, audio	Usually still loads, but the browser withholds the secure padlock and logs a warning, since an image itself carries little risk on its own.

A missing image and a broken layout are two different symptoms of the same underlying cause, which is why it's worth checking both categories rather than stopping once the page visually looks fine.

The causes, in the order worth checking

1. Hardcoded http:// links left over from before SSL was installed

Content, theme files, and configuration written before a site had HTTPS often reference resources with an explicit http:// prefix, which continues to load insecurely even after the site itself moves to HTTPS. On WordPress specifically, this frequently lives inside the database itself — in post content, in theme option fields, and occasionally in the site's own stored URL — rather than only in template files, which is why a simple find-and-replace across files alone often misses it.

An embedded video, a font, an advertising script, or any other resource pulled from an external service can trigger this if that service's own asset happens to be served without HTTPS. Check the exact URL shown in the console message — if it points to a domain you don't control, the fix is either finding that service's HTTPS equivalent URL or removing the embed if none exists.

3. A hardcoded asset URL in configuration

Some CMS platforms and page builders store a base URL for uploaded media or a CDN separately from the main site address, and that stored value can retain an old http:// prefix independently of everything else being correctly configured for HTTPS. Check any CDN, media library, or asset-path setting specifically, not just the main site URL field.

Fixing it without breaking serialized data

On WordPress, changing http:// to https:// directly with a plain SQL query is a common way to make things worse rather than better, because WordPress stores some content in a serialized format that records the exact character length of each string alongside it — and a plain text replacement changes the length without updating that count, corrupting the data structure around it. A search-and-replace tool built to understand serialized data avoids this entirely; if you are not confident distinguishing where serialized data is used, treat this as the one step in this whole guide worth getting help with before running it.

A relative-protocol or forced-HTTPS approach avoids the problem going forward

Writing internal links without an explicit protocol — //yourdomain.com/image.jpg rather than http:// or https:// — makes the browser use whatever protocol the current page is using automatically, which prevents this specific class of error from reappearing as content gets added over time.

Finding every instance, not just the first one

Open the browser's developer console and reload the page with it open — every mixed content resource on that page logs its own line, which is a far more complete list than checking visually for anything that looks obviously broken. Passive content in particular can load successfully while still being logged, so a page that looks fine can still be carrying several unresolved entries.

If you still see warnings after cleaning up obvious links

Send the exact console message, including the specific insecure URL it names. That URL identifies precisely which resource is still wrong, and with it support can tell you quickly whether it's something in your content, your theme, or a third-party service outside your control.

Frequently asked questions

Why does the page still say "Not secure" even after I fixed one mixed content error?

Because there is very often more than one. Each hardcoded http:// reference triggers its own separate console entry, and browsers commonly only display the padlock as fully secure once every one of them is cleared, not after the first fix.

Does this affect every visitor, or just people using certain browsers?

Every modern browser enforces this in some form, though the exact wording of the warning and whether the resource is blocked outright or merely flagged varies by browser and by resource type. Assume every visitor is affected in some way rather than treating it as one browser's quirk.