Mixed content is when an HTTPS page loads a resource — a script, stylesheet, image, or iframe — over plain HTTP. The page itself is encrypted, but that one resource isn't, which creates an opening: an attacker on the network can tamper with that insecure resource, and in the case of scripts, that can mean injecting arbitrary code into an otherwise secure page.
Active vs passive mixed content
Browsers distinguish between the two. Active mixed content — scripts, iframes, stylesheets — is blocked outright by default in modern browsers, because a compromised script can do real damage. Passive mixed content — images, video, audio — is usually just flagged with a warning, since a tampered image is lower-risk, though it still breaks the padlock's "fully secure" state.
Fixing it
Change hardcoded http:// references to https://, or better, protocol-relative/root-relative URLs. On platforms like WordPress, old content often has http:// URLs saved directly in the database, which requires a search-and-replace rather than just a settings change — see our HTTPS Migration guides for platform-specific steps.
Why the browser console is the fastest way to find the source
Opening browser DevTools' Console tab on the affected page shows mixed content warnings individually, each listing the exact URL of the offending resource — far faster than manually scanning page source, especially on a page where the resource is loaded dynamically via JavaScript rather than appearing in the static HTML.
Why some resources trigger a hard block and others just a warning
Active content like scripts and iframes is blocked outright by modern browsers by default, since a compromised script can inject arbitrary code into an otherwise secure page. Passive content like images is typically just flagged with a warning rather than blocked, since a tampered image carries meaningfully lower risk despite still technically breaking the page's fully-secure status.
Why fixing old content sometimes requires more than just a settings change
Content entered years ago through a CMS's rich text editor can have hardcoded absolute http:// URLs saved directly in the database, which a simple settings or configuration change won't touch — this specifically requires a database-level search-and-replace to fully resolve, not just updating a site-wide URL setting.
The specific related attack called BREACH worth knowing about
A related, separate vulnerability called BREACH applied similar compression-based information-leak logic to HTTP-level compression rather than TLS-level, meaning fixing mixed content and TLS compression issues alone doesn't fully address every related risk in this general category — application-level compression settings deserve their own separate review.
Why some CMS platforms handle this better than others out of the box
Modern CMS platforms increasingly generate protocol-relative or root-relative URLs by default rather than hardcoded absolute http:// links, meaning newer installations are less prone to mixed content issues than older sites whose content was originally created years before HTTPS became the assumed default.
A final practical note on prevention versus cleanup
It's considerably easier to prevent mixed content by using protocol-relative or HTTPS URLs consistently going forward than to retroactively clean up years of accumulated hardcoded links — worth establishing as a content standard at the same time you complete an HTTPS migration, not as an afterthought.
What role subresource integrity plays alongside fixing mixed content directly
Subresource Integrity, a separate but related browser security feature, lets you specify a cryptographic hash a loaded resource must match, providing an additional layer of protection for third-party resources even after they've been correctly migrated to HTTPS.
A closing thought
A quick closing thought: mixed content is one of the few HTTPS-related issues that's entirely within your own control to prevent through careful, consistent practice, unlike issues stemming from external factors like a visitor's outdated device.