LiveChat 
Support 
How to Fix SSL Insecure Content and Mixed Content Warnings
You installed an SSL certificate, your site loads over `https://`, and yet the browser still refuses to show a clean padlock. Instead you see “Not fully secure,” a broken lock icon, or a console full of red Mixed Content warnings. This is one of the most common post-migration headaches, and reaching for an SSL insecure content fixer plugin feels like the obvious solution. It usually isn’t the real one.
This guide explains what mixed content actually is, why browsers warn about or outright block it, how to find every offending resource, and how to fix it properly so the warning never comes back.
Key Takeaways
• Mixed content happens when an HTTPS page loads sub-resources (images, scripts, CSS, fonts) over insecure HTTP.
• Browsers block active mixed content (scripts, iframes, AJAX) and warn on passive content (images, video), breaking your padlock either way.
• Find offenders using browser DevTools console “Mixed Content” messages or an online scanner.
• The durable fix is updating the actual `http://` URLs in your database and code to `https://`, not masking them with a plugin.
• A `Content-Security-Policy: upgrade-insecure-requests` header is a useful safety net, not a substitute for clean URLs.
What Is Mixed Content and Why Does the Padlock Break?
Mixed content occurs when a page delivered over a secure HTTPS connection requests one or more of its sub-resources over plain, unencrypted HTTP. The main document is encrypted, but an image, stylesheet, script, font, or iframe inside it is not.
This is a problem because the security of an HTTPS page is only as strong as its weakest resource. An attacker on the network path can intercept or modify any HTTP resource in transit. If that resource is a JavaScript file, the attacker can effectively rewrite your entire page. Because of this, the browser cannot honestly tell the user the page is fully secure, so it downgrades the padlock and posts a warning.
Active vs. Passive Mixed Content
Browsers treat two categories very differently:
- Active mixed content includes scripts, stylesheets, iframes, XMLHttpRequest/`fetch` calls, and anything that can change the page or read its data. Modern browsers block these resources outright. The result is broken layouts, missing functionality, or features that silently fail.
- Passive (display) mixed content includes images, audio, and video loaded via `
`, `
The practical takeaway: a single hardcoded `http://` script tag can break your checkout or contact form, while a stray HTTP image just costs you the green padlock. Both deserve fixing.
How Do You Find Mixed Content on Your Site?
You cannot fix what you cannot see. Use these methods, in order of reliability.
1. Browser DevTools console. Open the page, press F12, and look at the Console tab. Browsers log explicit messages such as:
“` Mixed Content: The page at ‘https://example.com/’ was loaded over HTTPS, but requested an insecure script ‘http://example.com/js/widget.js’. This request has been blocked; the content must be served over HTTPS. “`
Each message names the exact resource and whether it was blocked or merely flagged. The Security tab (in Chromium-based browsers) gives a per-page summary as well.
2. View source and search. Use Ctrl+U to view the rendered HTML and search for `http://`. Hardcoded insecure links jump out quickly.
3. Online mixed content scanners. Several free tools crawl a URL and report every insecure resource across the page. They’re handy for spot checks and for resources injected by scripts that aren’t obvious in static source.
4. Site-wide crawl. For larger sites, a crawler that audits every page surfaces patterns, such as one widget or one CDN path that’s insecure across hundreds of URLs.
Here is the part most tutorials skip: an SSL insecure content fixer plugin or a catch-all header is a band-aid, not a cure. These tools rewrite `http://` to `https://` on the fly, every time a page renders, in PHP or in the browser. The insecure URLs are still sitting in your database and code. The day you deactivate that plugin, change themes, or migrate hosts, every warning returns. The real fix is to change the underlying URLs at the source with a database search-replace, so the problem is genuinely gone, not hidden behind a runtime filter.
What Causes Mixed Content and How Do You Fix Each Cause?
Most mixed content traces back to a handful of root causes. Match your symptom to the table, then apply the corresponding fix.
| Cause | Where it lives | The proper fix |
|---|---|---|
| Hardcoded `http://` URLs in content | Post body, widgets, page builder data | Database search-replace `http://yourdomain` → `https://yourdomain` |
| Old WordPress Site/Home URL | `wp_options` table, Settings → General | Update WordPress Address and Site Address to `https://` |
| Theme or plugin hardcoded links | Theme files, plugin assets | Edit source to `https://` or protocol-relative `//`; report to developer |
| Insecure CDN or asset host | Enqueued scripts and styles | Switch the CDN/asset URL to its HTTPS endpoint |
| External embeds over HTTP | YouTube, maps, fonts, ad tags | Update embed URLs to `https://`; replace providers that lack HTTPS |
| Resources injected by JavaScript | Third-party widgets | Configure the widget for HTTPS; add CSP as a backstop |
Fix 1: Update Hardcoded URLs to HTTPS
Wherever you control the markup, change `http://yourdomain.com/…` to `https://yourdomain.com/…`. For third-party resources that support both protocols, protocol-relative URLs are a clean option, the browser uses whatever protocol the page is on:
“`html
“`
Prefer explicit `https://` when you know the resource supports it; it’s the most predictable.
Fix 2: Do a Proper Database Search-Replace (WordPress)
In WordPress, the biggest source of mixed content is `http://` URLs baked into post content, serialized widget data, and page-builder layouts. You can’t fix these reliably with find-and-replace in a SQL editor, because serialized PHP arrays store string lengths that break if you naively swap text.
Use WP-CLI, which handles serialized data correctly:
“`bash
wp db export backup-before-replace.sql
wp option update home ‘https://yourdomain.com’ wp option update siteurl ‘https://yourdomain.com’
wp search-replace ‘http://yourdomain.com’ ‘https://yourdomain.com’ –all-tables –dry-run
wp search-replace ‘http://yourdomain.com’ ‘https://yourdomain.com’ –all-tables “`
This rewrites the actual stored values once, permanently. No plugin runs on every page load, and the warnings are gone at the source. If you don’t have shell access, a reputable, serialization-aware search-replace tool run once and then removed is the next best thing, far better than a permanent runtime “fixer.”
Fix 3: Add upgrade-insecure-requests as a Safety Net
The `Content-Security-Policy` directive `upgrade-insecure-requests` tells the browser to automatically request the HTTPS version of any HTTP sub-resource. It’s an excellent backstop for resources you can’t easily track down, but it should sit on top of clean URLs, not replace them.
Send it as an HTTP header (preferred) or a meta tag:
“`apache
Header always set Content-Security-Policy “upgrade-insecure-requests” “`
“`nginx
add_header Content-Security-Policy “upgrade-insecure-requests” always; “`
“`html
“`
Note the limitation: this only upgrades requests where an HTTPS version actually exists at the same URL. It won’t save a resource that simply isn’t available over HTTPS, which is why fixing the source URLs still matters.
Fix 4: Force HTTPS at the Server Level
Pair your fixes with a permanent redirect so every visitor lands on HTTPS in the first place:
“`apache
RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L] “`
Combined with clean internal URLs and an , this ensures the browser never even attempts an insecure top-level request.
Why Is a “Fixer Plugin” the Wrong Long-Term Answer?
A runtime fixer adds processing to every request, depends on staying active forever, and hides the underlying mess instead of cleaning it. The moment it’s disabled or your environment changes, the warnings reappear, often at the worst possible time. Updating the database and code once means the secure URLs are the real, stored values. Your site is faster (no extra filtering), more portable (migrations carry clean data), and genuinely secure rather than cosmetically patched.
Fix Mixed Content at the Source with DarazHost
A clean HTTPS migration is far easier on infrastructure built for it. DarazHost hosting includes a free SSL certificate on every plan plus the tooling to move your site to HTTPS properly, including WP-CLI access for serialization-safe database search-replace so mixed content is fixed at its root, not masked by a plugin. With fast SSD storage and 24/7 support that can run the migration with you, you get a fully secure padlock that stays secure. Explore and let our team handle the HTTPS cutover end to end.
What Should You Do After Fixing Mixed Content?
Once the warnings clear, lock the result in:
- Re-crawl the site and confirm a clean console on key templates (home, product, checkout, blog).
- Purge caches, including any CDN and page cache, so old HTTP markup isn’t served.
- Update sitemaps and canonical tags to the HTTPS versions and resubmit in Search Console.
- Audit third-party embeds periodically, since external providers occasionally revert to HTTP.
For a deeper hardening pass, see .
Frequently Asked Questions
Why does my site still show “Not secure” after installing SSL? Almost always because at least one resource on the page still loads over `http://`. The certificate is valid, but mixed content prevents the browser from certifying the page as fully secure. Check the DevTools console for the specific offending URLs.
Will a mixed content fixer plugin hurt my site? It won’t necessarily break anything, but it adds overhead and masks the real problem. It must stay active forever, and the moment it’s disabled or you migrate, the warnings return. A one-time database search-replace is the cleaner, faster, more durable fix.
What’s the difference between blocked and warned mixed content? Active content like scripts, stylesheets, and iframes is blocked, which can break functionality. Passive content like images and video is loaded but flagged, which breaks the padlock without breaking the page. Both should be fixed.
Does upgrade-insecure-requests fix everything? No. It upgrades HTTP requests to HTTPS only when an HTTPS version exists at the same address. It’s a strong safety net but can’t rescue resources that aren’t available over HTTPS, so cleaning the source URLs is still essential.
How do I safely do a search-replace on a WordPress database? Back up the database first, then use a serialization-aware tool such as WP-CLI’s `wp search-replace` (run with `–dry-run` first). Avoid raw SQL find-and-replace, which corrupts serialized data like widget and page-builder settings.
