Mixed content is an HTTPS page that loads some resources over plain HTTP. Modern browsers upgrade images, audio and video to HTTPS and block everything else, such as scripts, stylesheets, frames and fetch requests. The fix is to serve every resource over HTTPS and check the console to confirm.
The two categories
MDN now describes mixed content as upgradable or blockable, replacing the older active and passive terms.
Upgradable content (formerly passive) includes images in img with src, CSS images such as background images, and audio and video with src. Browsers upgrade these requests from HTTP to HTTPS.
Blockable content is everything else. That includes script src, link href (stylesheets), iframe src, fetch(), XMLHttpRequest, CSS URL values such as fonts, object data, sendBeacon, images using srcset or picture, and web fonts. Browsers block these when they are insecure.
Two details are worth knowing. Mixed downloads are blocked by default, though some browsers tell the user and let them keep or discard the file. And an upgradable request to an IP address, rather than a domain name, is blocked instead of upgraded, because there is no HTTPS version to try.
Why browsers are strict
An insecure script or stylesheet on a secure page can change the whole page. That was the "active" risk MDN describes as very high. An insecure image changes much less, so browsers try the upgrade first.
How to find it
- Open the browser developer console and look for mixed content warnings on each template, not just the home page.
- Set your browser to block all mixed content and see which pages break. MDN notes this is Safari's default.
- Crawl the site with a mixed content checker, such as the tools MDN lists.
- Search your templates and database content for hard-coded
http://URLs. Old blog posts and CMS fields are common sources.
How to fix it
- Serve your own content over HTTPS, and make every reference to your own resources relative or HTTPS, including downloads.
- For third-party resources, switch to the HTTPS URL if one exists and check that it works.
- Remove resources whose hosts do not support HTTPS.
- As a safety net, you can send the CSP directive
upgrade-insecure-requests, which upgrades all requests to HTTPS, including blockable ones. It helps with stragglers, but it is not a substitute for fixing the links. A resource whose host has no HTTPS version will still fail.
Content-Security-Policy: upgrade-insecure-requests
Related controls
HTTPS on the page is only part of transport hygiene. Cookies should carry the Secure attribute, and sites often add HSTS so browsers connect over HTTPS from the start. Those topics have their own posts in this blog.
Common mistakes
- Fixing the homepage and forgetting user-generated content.
- Using protocol-relative URLs from an old guide instead of explicit HTTPS.
- Assuming images are harmless: an upgraded image is fine, but one on a bare IP address is blocked.
- Using
upgrade-insecure-requeststo hide a link rot problem.
Quick check
Will a mixed content image break my page?
Usually the browser upgrades it. If the host cannot serve HTTPS, or the URL uses an IP address, the image fails to load.
Does localhost count as mixed content?
MDN says local resources such as loopback addresses count as secure origins.
Sources
Last reviewed: 19 October 2026.
