What Is Mixed Content and How to Fix It
You switched your site to HTTPS and the padlock shows up, but the browser still complains or parts of the page don't load. Often that's mixed content: your page is served over HTTPS while some images, scripts, styles or iframes are still requested over plain HTTP. Browsers block those requests or show warnings. Here's how to track them down and fix them.
Key takeaways
- Mixed content means an HTTPS page loading HTTP resources. Browsers block or warn about it.
- Find culprits in DevTools (Console and Network), or run your domain through our HTTPS report; we list mixed content when we detect it.
- Fix by changing URLs to
https://or using protocol-relative paths where it still makes sense, and update hardcoded links in content and config. - For WordPress or a CDN, use settings or plugins that force HTTPS for assets and fix old links in the database.
Why does it happen?
When you move to HTTPS, existing links and references in your HTML, CSS, or database often still point to http://. Themes, plugins, or old posts might embed images or scripts with absolute HTTP URLs. The page itself is secure, but those resources are not, so the browser treats them as mixed content and blocks or downgrades them depending on type (script vs image).
How to find mixed content
Open your site in Chrome or Edge, then DevTools (F12). In the Console you'll see messages like "Mixed Content: The page at ... was loaded over HTTPS, but requested an insecure resource ..." with the exact URL. In the Network tab, filter or look for requests that start with http:// while the page URL is https://. Our HTTPS checker also runs a real request to your domain and reports mixed content when it finds it, so you get a list without opening DevTools.
Fix hardcoded HTTP URLs
Where you control the markup or config, replace http://yourdomain.com with https://yourdomain.com. For assets on the same domain you can use relative paths (e.g. /images/logo.png) so the scheme follows the page. Search your codebase and any config or env files for http:// and update them. In WordPress, run a search-replace on the database for the old HTTP site URL and replace with HTTPS (use a proper DB search-replace tool or plugin to avoid breaking serialized data).
Nginx and Apache
You can't fix mixed content only in the server config if the URLs are in the HTML or CSS. But you can make sure your own assets are always served over HTTPS. Use relative paths in your templates, or set a base URL / canonical in your app so generated links use HTTPS. If you use a reverse proxy that terminates SSL, ensure X-Forwarded-Proto is set so the app knows it's on HTTPS and can build correct URLs.
Cloudflare and CDNs
With Cloudflare in front, your origin can be HTTP while visitors see HTTPS. If your HTML still contains http:// links to your own domain, the browser will request them as HTTP unless you fix the links. Use Cloudflare's "Always Use HTTPS" and fix the underlying URLs in your content or app. Some CDNs offer "rewrite HTTP to HTTPS" for responses; that can fix references in HTML they serve, but the clean fix is to output HTTPS (or relative) URLs from your app.
WordPress
After changing the site URL to HTTPS in Settings → General, old posts and media might still reference the HTTP URL. Use a plugin like Better Search Replace or WP Migrate to run a careful search-replace on the database (back up first). Plugins like Really Simple SSL can help force HTTPS for assets and fix some mixed content automatically. Also check theme and plugin settings for any place that stores the site URL; set them to HTTPS.
Verify there's no mixed content
After you've made changes, reload the page and check the Console again. Run your domain through our free HTTPS checker; the report includes a mixed content section when we detect HTTP resources on an HTTPS page. Once that section is clear, you're good.
Check your domain with HTTPS CheckerStuck on a specific URL or platform? We can help you figure out the next step.
Contact us