How to Fix Mixed Content Warning WordPress? (2026 Guide)

A mixed content warning on WordPress appears when an HTTPS page still loads at least one resource over insecure HTTP — usually an image, a script, a stylesheet, or an iframe. The browser breaks the padlock icon, shows “Your connection is not fully secure,” and in Chrome since 2020 it silently blocks the offending asset so your site looks broken.

I see this exact problem every week on sites that just installed an SSL certificate, switched hosts, or pushed a local build live. The good news: there are three reliable ways to fix it, and you can pick whichever matches your comfort level. Here is the quick overview:

1. Install the SSL Insecure Content Fixer plugin and step up its fix level until the warning disappears.
2. Run Better Search Replace in your WordPress database to swap every http:// URL for https://.
3. Edit your .htaccess file to force a 301 redirect from HTTP to HTTPS across every visitor.

Below I walk through every method step by step, plus what to do when the warning survives all three, when Chrome blocks images instead of warning you, and how to recover from an ERR_TOO_MANY_REDIRECTS loop if you stack a plugin on top of a server-level redirect.

What Is a Mixed Content Warning in WordPress and Why It Happens

A mixed content warning in WordPress is a browser-level notice that an HTTPS page is loading at least one sub-resource (image, JS, CSS, font, iframe, AJAX endpoint) over plain HTTP. Modern browsers refuse to mark the page fully secure, and Chrome since 2020 quietly blocks the insecure asset instead of just flagging it.

There are two flavours. Passive mixed content covers images, audio, and video — the page still loads, but the padlock is broken. Active mixed content covers scripts, stylesheets, iframes, and AJAX requests — browsers now block these outright, so forms, sliders, or menu dropdowns silently stop working.

Most of the sites I audit hit the warning for one of these reasons:

• An SSL certificate (usually Let’s Encrypt) was installed but old posts still hardcode http:// URLs.
• The site was migrated from a local environment (LocalWP, MAMP, XAMPP) to live hosting and the URLs never got swapped.
• A theme or page builder (Elementor, Divi) baked absolute http:// paths into widgets, CSS files, or saved templates.
• A CDN like Cloudflare is still serving cached HTTP copies of assets to visitors.
• A reverse proxy or load balancer is terminating SSL without the backend knowing.

If you just enabled HTTPS and the warning appeared overnight, that is the classic symptom. If the warning appeared after a migration, the database almost certainly still has old absolute URLs — and no plugin can rewrite theme files for you.

Symptoms and How to Find Which Assets Are Loading Over HTTP

The visible symptoms are easy to recognise. The padlock icon in the address bar is missing, broken, or replaced with a yellow triangle, the address bar may say “Not secure,” and Chrome might show “Your connection to this site is not fully secure.” On modern Chrome, image icons simply appear as broken placeholders with no warning at all.

To find exactly which assets are the problem, open Chrome DevTools with F12 (or right-click → Inspect) and switch to the Console tab. Reload the page and look for red entries starting with “Mixed Content: The page at ‘https://…’ was loaded over HTTPS, but requested an insecure image ‘http://…'”. Every line tells you the exact file path.

For a faster scan on bigger sites, I use two free online tools:

• Why No Padlock? (whynopadlock.com) — crawls a single URL and lists every insecure asset and its source line.
• Missing Padlock (missingpadlock.com) — same idea, slightly different reporting.

Write down or screenshot every URL the scanner flags before you start fixing. You will use that list to verify nothing is left at the end.

Method 1: Fix Mixed Content With the SSL Insecure Content Fixer Plugin

If you want the fastest fix with no code editing, install the free SSL Insecure Content Fixer plugin from WordPress.org. It intercepts insecure requests and rewrites them to HTTPS on the fly, with five escalating fix levels so you can stop as soon as the warning disappears.

Step by step:

1. In your WordPress dashboard, go to Plugins → Add New and search for “SSL Insecure Content Fixer.” Install and activate it.
2. Go to Settings → SSL Insecure Content Fixer.
3. Start at the Simple fix level and save. Clear every cache (plugin, server, CDN) and reload your homepage in an incognito window.
4. If the warning is still there, step up to Content, then Widgets, then Capture, then Capture All. Test after each change.
5. If your site sits behind a reverse proxy or Cloudflare, enable the HTTPS detection option so the plugin knows the real protocol.

Here is what each level catches, in plain English:

• Simple — scripts, stylesheets, and images registered through WordPress.
• Content — anything above, plus resources found in post content and widget text.
• Widgets — extends Content to every widget output.
• Capture — captures insecure URLs page-wide via output buffering.
• Capture All — the most aggressive level, last resort when older themes hardcode HTTP in their templates.

Once the warning is gone, leave the plugin active. It is lightweight and only does work when needed. As an alternative, the Really Simple SSL plugin handles the same job in one click with a “mixed content fixer” toggle, but it also forces HTTPS at the server level, which can fight a host that already redirects at the edge — that is where the redirect loop comes in, and I cover it in the troubleshooting section below.

Method 2: Replace HTTP With HTTPS in the WordPress Database

A plugin can only patch what WordPress renders. The actual URLs stored in your wp_options, wp_posts, wp_postmeta, and widget tables still say http://yourdomain.com. Until you rewrite them at the source, you stay one plugin-deactivation away from the warning returning.

The cleanest way to do that is the free Better Search Replace plugin. It understands WordPress serialized data, so it will not corrupt arrays in the options table.

Step by step:

1. Back up your database. Use your host’s backup tool, or a plugin like UpdraftPlus. Skip this and you are gambling.
2. Install and activate Better Search Replace from Plugins → Add New.
3. Go to Tools → Better Search Replace.
4. In Search for, enter your old URL with http://, for example http://yourdomain.com.
5. In Replace with, enter the same URL with https://, for example https://yourdomain.com.
6. Select every table — wp_options, wp_posts, wp_postmeta, wp_comments, and any custom tables from plugins.
7. Tick Run as dry run and click Run Search/Replace. Review how many rows it would change.
8. Untick dry run, run it for real, then clear every cache.

A Reddit r/Wordpress user confirmed Better Search Replace dry-run caught 200+ HTTP URLs hiding in wp_posts that no surface-level plugin could ever have fixed. That kind of report is exactly why I prefer this method for sites with years of legacy content.

If you build with Elementor, do one extra step: in your WordPress dashboard, go to Elementor → Tools → Regenerate CSS & Data. Elementor stores CSS file paths in its own cache and a URL change does not always invalidate them — until you regenerate, the broken stylesheet can keep firing HTTP requests.

If you would rather stay out of the dashboard, the wp search-replace WP-CLI command does the same thing in one line:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run

Drop --dry-run when you are happy with the output. WP-CLI is faster on large databases and skips PHP timeouts.

Method 3: Force HTTPS With a .htaccess 301 Redirect

The third method forces every visitor — humans and crawlers — to use HTTPS at the server level, regardless of what WordPress or your plugins say. It is the most permanent fix and the one I lean on for production launches.

You will edit the .htaccess file in the root of your WordPress install. Use your host’s File Manager in cPanel, an FTP client like FileZilla, or SSH — whichever you are comfortable with. Always download a copy of the existing .htaccess first so you can restore it if something breaks.

Add the following block above the existing WordPress rules. It does two things: redirects every HTTP request to HTTPS with a 301, and adds a Content-Security-Policy: upgrade-insecure-requests header so modern browsers automatically upgrade any remaining http:// requests before they leave the user’s machine.

# Force HTTPS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

# Upgrade any remaining HTTP requests in modern browsers
<IfModule mod_headers.c>
Header set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

What each line does, in plain English:

• RewriteCond %{HTTPS} off — only applies when the visitor is on HTTP.
• RewriteRule ... [L,R=301] — sends a permanent (301) redirect to the same URL on HTTPS. 301 is what you want for SEO; the redirect passes nearly all link equity.
• Header set Content-Security-Policy "upgrade-insecure-requests" — tells supporting browsers to silently rewrite any leftover HTTP requests. Supported in Chrome, Firefox, Edge, and Safari.

Save the file, clear your caches, and load the site over plain http:// first to confirm the redirect fires. If you use Nginx instead of Apache, the equivalent is a return 301 https://$host$request_uri; line inside the server block — your host’s support docs will have the exact placement.

If you would rather skip the file edit entirely, WordPress also accepts a one-line constant in wp-config.php:

define('FORCE_SSL_ADMIN', true);

This forces HTTPS for /wp-admin and login pages only — useful for hardening, but not a substitute for the .htaccess rule if you want the entire site on HTTPS.

Advanced Troubleshooting: ERR_TOO_MANY_REDIRECTS and Other Edge Cases

Sometimes the warning is gone but the site stops loading entirely with ERR_TOO_MANY_REDIRECTS. The cause is almost always a double redirect — a plugin is forcing HTTPS at the application layer while your host or Cloudflare is already doing it at the edge, so the request bounces between the two forever.

How to recover:

1. Open wp-config.php and add $_SERVER['HTTPS'] = 'on'; temporarily, just above the /* That's all, stop editing! */ line. This tells WordPress it is on HTTPS even when the variable is missing.
2. If you use Really Simple SSL, turn off its “301 redirect” toggle and let only the .htaccess rule do the redirecting.
3. If you sit behind Cloudflare, set SSL/TLS encryption mode to Full (strict) and turn on Automatic HTTPS Rewrites under the Edge Certificates tab. That alone solves a lot of mixed content for free-plan users.
4. Purge the Cloudflare cache, then your WordPress cache, then test in an incognito window.

A few other edge cases I have hit on real sites:

• Multisite / sub-domains. Each sub-site needs its own DOMAIN_CURRENT_SITE with HTTPS, and any sub-domain assets (CDN, media library mirror) need their own SSL certificate or a wildcard cert. Single-site guides skip this.
• Third-party assets. If an external script or iframe is hardcoded to http:// and you cannot control it, the CSP upgrade-insecure-requests header usually fixes it in modern browsers. For older browsers, contact the third party or replace the asset.
• Images silently vanishing. If Chrome auto-blocks an image and you see a broken-image icon with no warning, that is the post-April-2020 behaviour. Re-run the Why No Padlock scanner — it will still surface the URL.
• SEO follow-up. After the warning is gone, request re-indexing in Google Search Console for your top URLs. Google drops the “Not secure” label quickly, but a manual fetch speeds it up.

Post-Fix Verification Checklist

Once you have applied one of the three methods, walk through this list before you call it done. Each step catches a different class of leftover mixed content.

1. Reload the homepage in an incognito window (Ctrl+Shift+N in Chrome). The address bar must display a closed padlock with no warnings.
2. Open DevTools → Console and confirm there are no red “Mixed Content” entries.
3. Run Why No Padlock again. The report must come back clean for every important page (homepage, top landing pages, contact page, checkout).
4. Purge every cache in this order: plugin cache (WP Rocket, W3 Total Cache, LiteSpeed), server cache (your host’s control panel), CDN cache (Cloudflare), and your browser cache.
5. Run an SSL Labs scan (ssllabs.com/ssltest) for a quick sanity check on the certificate itself — a misconfigured cert will look like a mixed content issue but is a different fix.
6. Open Google Search Console and use URL Inspection → Request Indexing for your top five URLs. This speeds up Google’s re-crawl so the “Not secure” label disappears faster.

If any step still flags an insecure URL, the cause is usually a theme file (header.php, footer.php, a hardcoded background image in style.css) that no plugin has scanned. Open the theme file via Appearance → Theme File Editor or FTP and replace the remaining http:// references manually.

Frequently Asked Questions

Conclusion

Fixing a mixed content warning on WordPress comes down to three reliable methods: an SSL plugin for the fastest one-click patch, a database search-and-replace to clean up the actual stored URLs, and a .htaccess 301 redirect with a Content-Security-Policy header to lock HTTPS in at the server level. Stack the three in that order, verify in an incognito window, and the warning stays gone for good.

If you take one thing from this guide, take the backup before Method 2. A working database backup turns a stressful mistake into a five-minute restore. After the fix lands, request re-indexing in Google Search Console so the “Not secure” label disappears from search results as fast as possible, and your site is fully clean.