Is mixed content always a security problem?

Yes, because the secure page is still loading at least one insecure resource. Even when the browser only shows a warning, the page is not fully secure.

Why does the warning disappear in one browser but not another?

Different browsers handle mixed content and cached assets a little differently. One browser may block a resource that another browser loads, or one may be showing an outdated cached version.

Can I fix mixed content with a plugin?

Sometimes a plugin can help replace old URLs, but it is not always enough. If the insecure link is in theme code, a CDN setting, or a builder template, the source still needs to be corrected.

Do I need to change every old http:// link on the site?

You should fix any internal or asset URLs that belong to your site or stack. External links to other websites do not usually affect your padlock unless they are loading page assets.

Mixed Content Warnings from CDN and Asset URLs

If your padlock won’t turn green after switching WordPress to HTTPS, the cause is usually one or more old HTTP URLs still loading on the page. The fastest fix is to find the insecure asset URLs, update them to HTTPS, and clear every cache in the stack — WordPress, your CDN, your host, and your browser.

This is not usually a “broken SSL certificate” problem. It is more often a content problem: one image, stylesheet, script, font, iframe, or background image is still being requested over HTTP, so the browser marks the page as mixed content.

In practice, this shows up as a padlock that stays gray, a warning icon in the address bar, console errors, missing images, or styling that loads on some pages but not others. If you want a broader walk-through of the main mixed-content fix patterns, see our WordPress fix guides and the related post Why WordPress Padlock Won’t Turn Green: Mixed Content Fix.

What mixed content means

Mixed content happens when the main page loads over HTTPS, but one or more resources on that page still load over HTTP. Modern browsers treat that as a security issue because an insecure resource can be intercepted or altered before it reaches the page.

There are two common types:

Passive mixed content: images, video, audio, fonts, and similar assets.
Active mixed content: scripts, stylesheets, and some embedded content. These are more likely to break the page or get blocked entirely.

That’s why a site can “mostly work” while still showing a warning. The problem may only affect the homepage banner, a CSS file from your CDN, or one hard-coded link in a theme template.

Why this happens after an HTTPS migration

The most common cause is an incomplete URL change during the move from HTTP to HTTPS. WordPress stores URLs in several places, and not all of them update automatically.

Typical sources include:

The WordPress Site Address and WordPress Address
Image URLs saved in posts, page builders, or widgets
Theme options with custom logo, background, or font URLs
Hard-coded links in theme files or custom snippets
CDN or asset URLs that still point to http://
Plugin settings that store their own asset paths
Cached HTML that was generated before the HTTPS change

In some cases, the site actually loads secure assets from the right origin, but an old cache or proxy keeps serving an outdated page version. That is why mixed content can appear “randomly” across different devices or browsers.

How to find the exact insecure file

Do this first before changing anything else. You need to identify the specific URL that is being loaded over HTTP.

Open the page in Chrome, Edge, or Firefox.
Right-click the page and open the browser developer tools.
Check the Console for mixed content warnings.
Look for URLs starting with http://.
Refresh the page and note which file is flagged repeatedly.

If the browser only says “blocked mixed content” without naming the source, inspect the page source or the Network tab and look for insecure requests. Pay close attention to CSS files, JavaScript files, fonts, background images, and embeds loaded from a CDN or third-party domain.

You can also view the page source directly and search for http://. That is often the quickest way to spot a leftover image URL, stylesheet link, or embedded script.

Safe ways to fix it

Before making changes, back up your site. If your host offers one-click backups or snapshots, use that. If you have staging, test there first.

1) Update the site URLs in WordPress

Check Settings > General and confirm both URL fields use https://. If either field still uses HTTP, WordPress may keep generating insecure links.

Only change these if you understand the impact and can log back in afterward. In most normal migrations, both values should match the secure domain exactly.

2) Replace old HTTP URLs in content

If posts, pages, or builder content contain hard-coded HTTP links, update them to HTTPS. A search-and-replace is often the cleanest fix, but it should be done carefully because serialized data can break if handled incorrectly.

Use a tool that understands WordPress data structures, or a trusted migration/search-replace process from your host. Avoid editing the database directly unless you are confident and have a fresh backup.

3) Check theme and plugin settings

Many themes and plugins store logo URLs, header images, social icons, custom CSS backgrounds, and font references in their own settings pages. Re-save those settings after switching to HTTPS.

If you use a page builder, open the relevant templates and resave them so any regenerated asset links use the secure scheme.

4) Fix hard-coded theme files

If the insecure URL is in a theme template, custom plugin, or code snippet, update it at the source. Look for http:// references in theme files, custom CSS, and functions files.

Be careful here: changing the wrong file can break the site. If the link is inside a child theme or custom plugin, update that copy rather than editing the parent theme directly.

5) Verify CDN settings

If you use a CDN, confirm that its asset URLs and origin settings are using HTTPS. A very common problem is an HTTPS page pulling images or CSS from an HTTP CDN endpoint, especially after a domain change or cache purge.

Clear the CDN cache after making changes. Then clear your host cache, any plugin cache, and your browser cache.

6) Add a temporary redirect if needed

If older HTTP links still exist in the wild and you need a safety net, set up a sitewide redirect from HTTP to HTTPS at the server level. This helps users and search engines land on the secure version.

That said, redirects do not fix mixed content by themselves. The page source still needs to load secure URLs directly.

7) Use a content security approach, not just a visual fix

Some people try to hide the warning by forcing browser behavior with a plugin. That can mask the symptom, but it does not clean the insecure URLs themselves.

The reliable fix is to remove the HTTP references so the page is genuinely secure, not just cosmetically “green.”

What to check if the padlock still won’t turn green

If you have updated URLs and the warning remains, the problem is often being served from cache or hidden inside a less obvious asset source.

Open the site in an incognito/private window.
Test after clearing browser cache.
Purge any page cache, object cache, and CDN cache.
Check widgets, reusable blocks, and footer/header builders.
Inspect background images defined in custom CSS.
Look for embedded content from old HTTP embeds or third-party widgets.

Fonts are a frequent culprit. A theme may load Google Fonts or local font files over HTTP even when the main page is secure. Another common source is a header logo or hero image inserted in a theme options panel long ago.

How to prevent mixed content from coming back

The best prevention is to treat HTTPS as part of your setup, not a one-time migration step.

Use HTTPS URLs everywhere you enter a link.
Prefer relative or protocol-aware asset URLs when appropriate.
After major design or plugin changes, test the page source for http://.
Clear caches after updates that affect templates or media.
Keep one browser console check in your launch checklist for new pages.

If you manage a larger site, add a quick HTTPS audit to your release process. That is much easier than hunting down a single insecure asset weeks later.

When to call a professional

If the warning appears sitewide, keeps returning after fixes, or seems tied to a migration, CDN, or page builder, it may take deeper inspection than a simple search-and-replace. The same is true if you are seeing mixed content plus broken layouts, missing scripts, or a checkout page that behaves differently in HTTPS.

That is a good point to hand it off. Mend can diagnose the source, fix it safely, and give you a plain-English report of what changed. Start with a free diagnosis at /start/diagnosis, or if you already know the site needs hands-on cleanup, use /start/quick_fix for a flat-price fix. Access is handled securely through /connect, with no password sharing.

If the mixed content issue is part of a larger broken-site problem after an update or migration, our engineers can usually move faster with a full rescue workflow. See /start/emergency for urgent help.

Bottom line

A padlock that won’t go green is usually telling you that one or more assets are still loading over HTTP. Find the exact insecure URL, update it at the source, clear every cache, and verify the page source again after the change.

If you want this handled without guesswork, Mend fixes WordPress issues with a backup-first workflow and fixed pricing. For ongoing protection after the cleanup, a Care Plan can help keep updates, backups, and monitoring from drifting into the same problem again.