Browser errors
Mixed content warning: fix HTTP resources on HTTPS pages
Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure resourceA mixed content warning means an HTTPS page is loading some of its files over plain HTTP. The page itself is encrypted, but the HTTP pieces are not, so browsers block scripts and frames and may upgrade or block images. The result ranges from a missing padlock to a broken layout or a non-working button.
Is it the site or your device?
Mixed content is almost always the site's own code. Visitors cannot fix it and should not need to. Rarely, a browser extension or a proxy that injects HTTP content (for example ad or analytics injection on some networks) causes it; an incognito window or a different network rules that out.
Start with the SSL checker to confirm the certificate itself is fine:
curl ssl.sh/example.com
Then scan the page with the mixed content scanner, or open DevTools (F12) > Console and look for lines beginning with "Mixed Content".
Causes
1. Hard-coded http:// URLs in templates or content
Old posts, theme files and editors often store absolute http:// URLs. Find them:
curl -s https://example.com/ | grep -oE 'src="http://[^"]+"|href="http://[^"]+\.css"' | sort -u
2. CMS still configured for HTTP
WordPress and similar systems build URLs from a stored site address. If it still says http://, every generated link is insecure.
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid
3. Third-party resources without HTTPS
Old widgets, counters, image hosts or CDNs that do not offer HTTPS. Replace them or host the files yourself.
4. Backend behind a proxy thinks it is on HTTP
When TLS ends at a load balancer or CDN, the application may see plain HTTP and generate http:// links. Pass X-Forwarded-Proto and configure the app to trust it.
What it looks like in each browser
| Browser | What you see |
|---|---|
| Chrome / Edge | Console: "Mixed Content: The page at ... was loaded over HTTPS, but requested an insecure ..."; the site info icon reports the connection is not fully secure |
| Firefox | Console: "Blocked loading mixed active content"; padlock with a warning |
| Safari | Web Inspector console reports blocked insecure content |
How site owners fix it
Loading every resource over HTTPS removes the warning.
1. Change every resource URL to https:// or to a relative path. Search the codebase and database, not only the front page.
2. Add a safety net header while you clean up:
add_header Content-Security-Policy "upgrade-insecure-requests" always;
3. Tell the app it is behind HTTPS.
proxy_set_header X-Forwarded-Proto $scheme;
4. Redirect HTTP to HTTPS and, once everything loads cleanly, consider HSTS so browsers never use HTTP for your site again.
5. Re-scan with the mixed content scanner and check the console on key pages.
FAQ
Is mixed content dangerous for visitors?
An HTTP script or frame on an HTTPS page can be modified by anyone on the network path, which can compromise the whole page. That is why browsers block it. Images are lower risk but can still leak what you are viewing.
Can I allow insecure content in the browser settings instead?
Chrome lets you allow it per site, but that only changes your own browser and weakens protection for that site. As a visitor, prefer to leave it blocked. As an owner, fix the URLs so nobody needs to change settings.
Will upgrade-insecure-requests fix everything?
It rewrites http:// subresource URLs to https:// before the request is made, which works only if the resource is available over HTTPS. Resources on hosts without HTTPS will fail, so you still need to fix or replace them.