Fix mixed content by making sure every subresource on your page loads over HTTPS or by removing the reference entirely, understanding the browser warnings from The Role of Browser Security Warnings Explained. Start with Chrome DevTools: open the Issues panel, review the Security tab, and let the Network panel point you to the exact insecure requests. Some resources will autoupgrade silently, but scripts, iframes, and XHR calls that can't load securely will simply break, so treat every warning as something to fix, not just watch.
TL;DR:
- Browsers silently upgrade images, audio, and video, but block scripts, stylesheets, iframes, fonts, and network calls that cannot load over HTTPS.
- Start with Chrome DevTools’ Issues panel, cross check Security, then inspect Network requests; use a sitewide crawler to find old content and third party embeds.
- WordPress fixes should use search and replace tools that preserve serialized data, because raw database updates can corrupt stored content.
- Treat the CSP request upgrade rule as temporary, and enable HSTS with includeSubDomains only after confirming HTTPS works on every subdomain.
- Prioritize login and payment pages, where blocked scripts can disrupt checkout or authentication, then clear the browser cache and scan the entire site again.
Table of Contents
- What Counts as Mixed Content and What Gets Blocked
- How Browsers Decide to Autoupgrade or Block
- Finding Every Instance of Insecure Content on Your Site
- Fixing Mixed Content: A Prioritized Checklist
- Confirming the Fix and Catching Regressions
- Fixing Mixed Content on WordPress, CDNs, and Legacy Sites
- Tools That Help You Verify and Monitor the Fix
- What to Fix First When You're Short on Time
- Keep HTTPS Clean After the Fix
- FAQ
- Sources
What Counts as Mixed Content and What Gets Blocked
Mixed content happens when an HTTPS page loads a resource over plain HTTP. Browsers split these resources into two buckets, and how your page behaves depends entirely on which bucket a given resource falls into.
Upgradeable content includes images, audio, and video. Browsers silently rewrite the request to HTTPS, and if that fails, the resource just doesn't load, often with no visible console warning beyond a failed network request. Blockable content includes scripts, stylesheets, iframes, fonts, and XHR or fetch requests. These carry real security risk because they can manipulate the page, so browsers block them outright.
- Upgradeable: images, audio, video tags get an automatic HTTPS rewrite attempt.
- Blockable: scripts, iframes, CSS, fonts, and XHR/fetch calls are blocked if they can't be served over HTTPS.
- Mixed downloads: files initiated for download from an HTTPS page carry separate risk.
Mixed downloads deserve their own mention. According to the W3C mixed content specification, browsers block insecure downloads initiated from secure pages because they can escape the browser's sandbox protections or expose sensitive data in transit. This isn't the same risk profile as a broken image: a mixed download can hand an attacker a foothold outside the page itself, which is why the spec treats it as a hard block rather than a warning.
Mixed content blocking exists because autoupgrading alone isn't a security guarantee, according to the W3C, it reduces breakage while the web transitions away from HTTP, not a replacement for actually serving everything securely.
The practical effect for you: a page can look fine in casual browsing while quietly failing to load a video thumbnail, and look completely broken when a blocked script kills page functionality. Both are mixed content, but only one of them screams for attention.
How Browsers Decide to Autoupgrade or Block
Browser behavior around mixed content isn't arbitrary. It follows a published specification, and understanding the logic behind it helps you fix root causes instead of chasing symptoms page by page.
The W3C mixed content spec defines which resource types get autoupgraded and which get blocked, and it ties decisions to the concept of a "potentially trustworthy URL," meaning a URL whose origin a browser can treat as secure even if the scheme isn't literally HTTPS (localhost being a common example). Resources that fail this test and can't be upgraded are blocked rather than silently degraded.
A few mechanics worth knowing:
- Potentially trustworthy origins let browsers treat certain non-HTTPS contexts (like local development) as secure without weakening production rules.
- CORS and fetch mode interact with mixed content checks, so a cross-origin request can fail for both reasons at once, which muddies debugging if you don't check both.
- User agent settings can override default blocking behavior, which is why a site can look fine for one tester and broken for another on the same browser family.
Rollout timing also explains inconsistent behavior across teams. Chrome phased in autoupgrading and blocking for images, audio, and video across several releases rather than flipping a single switch, a pattern documented in the Chromium team's own announcement of the policy shift. Firefox and other browsers adopted similar protections on their own timelines, which is why a site that passes in one browser version can still trip warnings in another, especially on older installs that haven't picked up the latest mixed content rules.
Finding Every Instance of Insecure Content on Your Site
Hunting down mixed content is mostly a matter of following the right trail in the right order. Here's the sequence that gets you from "something's broken" to "here's the exact URL" fastest.
- Reproduce the page in Chrome with DevTools open, then check the Issues panel first. According to Chrome's own documentation, the Issues panel aggregates security problems and links directly to the Network panel entries responsible, which cuts diagnosis time significantly compared to scanning console logs line by line.
- Cross-check the Security tab for a broader read on certificate and connection status, since mixed content sometimes shows up alongside certificate warnings that share a root cause.
- Open the Network panel and filter by scheme or search "http://" in the request URLs to catch anything the Issues panel summarized rather than listed individually.
- Run an automated crawler across the full site. Tools like LinkChecker, HTTPSChecker, Mixed Content Checker, or mcdetect walk every page and flag insecure references without you clicking through manually, which matters once you're past a handful of pages.
- Search the codebase directly. A quick
grep -r "http://" .orrg "http://"across templates, stylesheets, and JavaScript often surfaces hardcoded links that never show up in a single-page DevTools session. - Inspect service worker caches. A service worker can keep serving cached HTTP responses even after the origin fully moves to HTTPS, so check
caches.keys()in DevTools' Application panel and review fetch handlers for hardcoded schemes. - Check build pipelines and templates for environment variables or config files that still hardcode
http://for asset base URLs, especially in older CMS themes or custom build scripts.
Pro Tip: Bookmark the DevTools Issues panel workflow and walk new team members through it once. Linking warnings directly to Network entries turns a half-hour hunt into a two-minute fix.
Between DevTools for one-off pages and a crawler for the whole site, you'll typically find insecure references in three places: hardcoded links in old content, third-party embeds that never upgraded, and leftover cache entries from before the HTTPS migration.
Fixing Mixed Content: A Prioritized Checklist
Once you know where the insecure references live, fix them in order of effort versus impact. Quick text replacements first, then platform-level changes, then the header and caching work that prevents regressions.
Start with the obvious wins:
- Replace every
http://reference withhttps://across templates, page content, and stylesheets. - Prefer explicit
https://URLs over protocol-relative ones (//example.com/asset.js) wherever the resource might be used outside a browser context, since MDN notes that protocol-relative links can misbehave in emails and certain embeds. - Update any absolute URLs stored in content fields, not just template code.
Database and CMS-level fixes need more care than template edits. A blind find-and-replace against a WordPress database can corrupt serialized data, since PHP serialization stores string lengths alongside the string itself. Use WP-CLI's search-replace command with serialization support, or a dedicated tool like the interconnect/it Search and Replace script, rather than a raw SQL UPDATE. Plugins such as SSL Insecure Content Fixer automate a meaningful share of fixes but documentation for the plugin itself notes that some references still need manual cleanup, particularly ones buried in serialized widget or theme data.
Edge and CDN configuration is often the fastest lever for sites with assets served through a content delivery network. Enable HTTPS rewrite rules at the CDN layer where available, update origin configuration so assets are requested securely from the start, and purge caches after the change so you're not serving stale HTTP-referencing pages to new visitors.
Security headers close the gap during transition. The CSP directive upgrade-insecure-requests tells the browser to rewrite insecure requests automatically across the page, which works well as a stopgap while you track down every hardcoded reference. MDN's guidance recommends pairing it with HSTS, since upgrade-insecure-requests only acts after the browser has already loaded the page, leaving a brief window where an SSL-stripping attack could intervene before that rewrite happens. Configure HSTS with includeSubDomains, and add preload once you're confident every subdomain is HTTPS-only.
- Set
Content-Security-Policy: upgrade-insecure-requestsas a transitional measure, not a permanent fix. - Configure HSTS headers with
includeSubDomainsonce all subdomains are confirmed HTTPS-ready. - Skip the legacy
block-all-mixed-contentdirective, since MDN confirms it's obsolete in favor ofupgrade-insecure-requests.
Service workers need explicit attention. Update fetch handlers to reject or rewrite insecure scheme requests, and invalidate old caches that might still hold HTTP-sourced responses from before your migration.
Third-party assets are the stubborn category. If a third-party host genuinely can't serve HTTPS, host the asset yourself or find an alternative provider. For scripts you must load from elsewhere, add Subresource Integrity (SRI) hashes where the provider supports them, which protects against a compromised or altered file even when you don't control the hosting.
Pro Tip: Fix third-party script dependencies last if they're non-critical. Chasing a vendor's HTTPS support can stall a fix that should take an afternoon.
Confirming the Fix and Catching Regressions
A fix isn't done until you've verified it in the browser and set up a way to catch it if it breaks again after the next deployment.
Reload the page with DevTools open and check the Security panel for a clean padlock with no warnings, then confirm the Issues panel is empty. Record the specific request URLs you removed or upgraded so you have a reference if the same page regresses later. Run a crawler like LinkChecker or Mixed Content Checker across the full site rather than just the pages you remember editing, since insecure references tend to hide in old blog posts and rarely visited template includes.
- Reload with an empty cache to rule out a stale service worker masking the fix.
- Re-run your crawler against the full sitemap, not just the pages you edited.
- Spot-check third-party embeds separately, since they can reintroduce HTTP links on their own schedule.
| Check | Tool type | Expected result |
|---|---|---|
| Page-level warnings | Browser Security/Issues panel | No mixed content entries |
| Site-wide scan | Crawler (LinkChecker, Mixed Content Checker, mcdetect) | Zero http:// references in reports |
| Certificate validity | SSL checker | Valid chain, no expiry warnings |
| Header configuration | Response header inspector | HSTS and CSP present as configured |
Once the fix holds, set up scheduled checks so you're not relying on manual spot-checks after every deployment. A synthetic uptime check against your critical pages combined with a periodic SSL check catches both availability regressions and certificate issues before a customer does.
Fixing Mixed Content on WordPress, CDNs, and Legacy Sites
Certain platforms produce the same mixed content problems over and over, so it's worth knowing the fix pattern for each.
- WordPress: run a serialization-aware search-and-replace (WP-CLI or interconnect/it's script), not a raw database query, and treat plugins like SSL Insecure Content Fixer as a first pass rather than a complete solution.
- CDN and edge: enable automatic HTTPS rewrite rules where your provider supports them, update origin URLs so new requests never start as HTTP, and purge the cache immediately after the change so stale pages don't linger.
- Legacy templates and build pipelines: check build configs and environment variables for hardcoded
http://asset base URLs, rebuild, then clear both CDN and client-side caches so visitors don't keep loading the old output. - Iframes and embeds: confirm the embedded source itself supports HTTPS before swapping the URL; a naive protocol swap on an iframe pointing to a host without a valid certificate just trades one broken embed for another.
Tools That Help You Verify and Monitor the Fix
Catching mixed content once is one thing; keeping a site clean after every deployment is another. A handful of free checks can cover both ends of that problem.
- Run our SSL Checker after any certificate or origin change to confirm the chain is valid and nothing in your mixed content fix accidentally broke the handshake.
- Use our Response Headers Inspector to confirm HSTS and Content-Security-Policy headers are actually present and correctly scoped, since a typo in either one quietly undoes the protection.
- Schedule our Website Uptime Monitor on pages that handle logins or payments, so a regression after a future deploy shows up as an alert instead of a support ticket.
- Check our HTML reference on unclosed tags when a malformed template is hiding an insecure reference inside broken markup.
What to Fix First When You're Short on Time
Not every mixed content warning deserves the same urgency. Fix login and payment pages first, since blocked scripts there can break checkout flows or authentication outright, then move to high-traffic pages where a degraded experience affects the most visitors.
Treat upgrade-insecure-requests as a bridge, not a destination. It buys you time, but the permanent fix is still replacing every hardcoded HTTP reference. When a third-party host refuses to support HTTPS, or when downloads start getting blocked in production, that's the point to loop in your CDN provider's support team or your security operations group rather than trying to patch around it indefinitely.
— Andreas
Keep HTTPS Clean After the Fix
Fixing mixed content once is straightforward. Catching it again after the next redesign, plugin update, or CDN change is the part teams usually skip, and it's the part that actually prevents the next incident.
Run our free SSL Checker right after you deploy a fix to confirm the certificate chain is intact, then check response headers with our Response Headers Inspector to verify HSTS and CSP are configured the way you intended. For pages where a regression would actually hurt, like login or checkout, set up our Website Uptime Monitor so you hear about a broken page before your visitors do.
FAQ
How do I unblock mixed content in Chrome?
You don't unblock it from the browser side; you fix the underlying page so every resource loads over HTTPS. If you're debugging locally and need a temporary workaround, Chrome's site settings allow insecure content for that specific site, but this isn't a fix and doesn't help your visitors.
How do I allow mixed content in Chrome for testing?
In Chrome, click the padlock or site information icon, open Site Settings, and change the "Insecure content" permission to allow for that domain during local testing only. This setting is per-browser and per-device, so it has no effect on what other visitors to your site experience.
How do I fix a "not secure" warning on my website?
A "not secure" warning usually means your page is missing a valid SSL certificate or is still loading some resources over HTTP. Run an SSL check to confirm your certificate is valid, then use the DevTools Issues panel described above to find and fix any remaining insecure resource references.
What's the difference between upgradeable and blockable mixed content?
Upgradeable content, mainly images, audio, and video, gets automatically rewritten to HTTPS by the browser, while blockable content like scripts, iframes, fonts, and XHR requests is blocked outright if it can't load securely, according to the W3C mixed content spec. This distinction determines whether a mixed content issue shows up as a silently missing image or a fully broken page feature.
Does mixed content affect SEO?
Mixed content itself isn't a direct ranking factor, but the broken scripts, failed resource loads, and "not secure" browser warnings it causes hurt user trust and can increase bounce rates, which indirectly affects how a page performs. Fixing mixed content is really about restoring the secure, functional experience that search engines and visitors both expect from an HTTPS page.