After migrating to HTTPS, browsers may flag "mixed content" — a secure page loading some resources over plain HTTP, undermining the security benefit and sometimes causing those resources to be blocked entirely.
What Mixed Content Means
When an HTTPS page includes references to HTTP resources (images, scripts, stylesheets), browsers flag this as mixed content since the HTTP portion of the page isn't actually protected by encryption, creating a security gap in an otherwise secure page.
Active vs Passive Mixed Content
Active mixed content (scripts, stylesheets, iframes over HTTP) is typically blocked outright by modern browsers, since these can directly manipulate page behavior — a bigger functional problem.
Passive mixed content (images, video, audio over HTTP) is usually allowed but flagged with a warning, since these pose a lower (but not zero) security risk.
Step 1 — Identify Mixed Content Sources
Open your browser's developer console on the affected page — mixed content warnings appear explicitly, listing the specific HTTP URLs causing the issue.
Step 2 — Search Your Codebase for Hardcoded HTTP URLs
grep -r "http://yourdomain.com" /var/www/yoursite/
Step 3 — Update Hardcoded URLs to HTTPS
Replace explicit http:// references with https://, or better, use protocol-relative URLs where appropriate:
<img src="//cdn.example.com/image.jpg">
Protocol-relative URLs automatically match the current page's protocol, avoiding hardcoding either HTTP or HTTPS.
Step 4 — Check for Mixed Content in a Database (Common in CMS Platforms)
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
Content stored in a database (like WordPress post content) needs the same URL updates — always back up the database before running bulk replace queries.
Step 5 — Check Third-Party Embeds and Widgets
External embeds (social media widgets, ad scripts, analytics) sometimes hardcode HTTP URLs on the third-party's end — check whether the third-party provider offers an HTTPS version of their embed code.
Step 6 — Use Content-Security-Policy to Auto-Upgrade Insecure Requests (Quick Fix)
add_header Content-Security-Policy "upgrade-insecure-requests";
Instructs the browser to automatically upgrade HTTP resource requests to HTTPS — a useful stopgap while you address the root cause, though not a substitute for actually fixing the hardcoded URLs, since it doesn't work if the resource genuinely isn't available over HTTPS.
Step 7 — Re-Scan After Fixes
Reload the affected pages and check the browser console again to confirm all mixed content warnings are resolved.
Preventing Future Mixed Content Issues
Always use protocol-relative or explicit HTTPS URLs when adding new content/resources going forward, and consider a CSP report-only policy to catch new instances proactively before they reach production visitors.
Common Errors
Images load but browser still shows a warning icon — even passive mixed content triggers a "not fully secure" indicator in many browsers; address all instances, not just the actively-blocked ones, for a genuinely clean HTTPS implementation.
Continue Reading
- HTTP to HTTPS Redirect: Forcing SSL on Nginx & Apache
- How to Install Let's Encrypt SSL with Certbot (Nginx & Apache)
- Understanding HTTP Security Headers (CSP, HSTS, X-Frame-Options)
Browse more articles in SSL/TLS & Certificates.