HTTPS/HTTP mixed content
Last updated 14 May 2026 3 min
Mixed content occurs when a page served over HTTPS loads sub-resources (images, scripts, stylesheets, iframes, fonts) over HTTP. The page itself is encrypted, but pieces of it aren't — which undermines the whole point of HTTPS.
A single unsecured resource will cause browsers to respond with warnings, blocked resources, and broken layouts, potentially creating the appearance that the entire site is a risk.
Why HTTPS matters
HTTPS encrypts traffic between the browser and the server, which:
- Prevents network attackers from reading or modifying the data.
- Protects user credentials, payment info, and personal data.
- Is required for modern browser features (geolocation, service workers, push notifications, HTTP/2).
- Is a confirmed Google ranking signal.
- Avoids "Not Secure" warnings in browser address bars.
If a page is HTTPS but pulls in HTTP resources, all of these benefits are weakened or lost for those resources.
Active vs. passive mixed content
Browsers treat the two categories differently because they pose different risks.
Active mixed content (blocked by default)
Resources that can change the behaviour of the page:
- Scripts (
<script src="http://...">) - Stylesheets (
<link rel="stylesheet" href="http://...">) - Iframes (
<iframe src="http://...">) - XMLHttpRequest / Fetch requests
- Web fonts in some configurations
Because a bad actor can modify these in transit and inject code into the page, modern browsers (Chrome, Firefox, Safari, Edge) block them outright. This results in broken layouts, missing functionality, JavaScript errors, and more.
Passive mixed content (allowed but flagged)
Resources that display but don't execute:
- Images (
<img src="http://...">) - Audio and video (
<audio>,<video>) - Some
<object>content
In the past, browsers allowed these, but flagged the page as not fully secure. Chrome has been progressively auto-upgrading these to HTTPS where possible, falling back to blocking when the upgrade fails.
How mixed content happens
- Hardcoded HTTP URLs in templates, content, or CSS files (e.g.,
background-image: url(http://example.com/bg.jpg)). - Old CMS posts with absolute HTTP URLs in image references.
- Internal linking still using HTTP after a site has migrated to HTTPS.
- Hardcoded references in JavaScript files.
- CDN configurations serving over HTTP when the main site is HTTPS.
How to fix it
1. Replace HTTP URLs with HTTPS
For every hardcoded reference, change http:// to https://. If the resource isn't available over HTTPS, find an alternative or self-host it.
2. Use protocol-relative URLs (legacy approach)
//example.com/asset.jpg adapts to whichever protocol the page is using. Modern best practice is to use explicit https:// instead, but protocol-relative still works.
3. Database-level find and replace
For WordPress and similar CMSs, plugins like Better Search Replace (or the WP-CLI command wp search-replace) can update all stored URLs in one operation. Always back up first.
4. Configure HSTS
HTTP Strict Transport Security (HSTS) tells browsers to only ever use HTTPS for the domain. Once HSTS is active, browsers won't even attempt HTTP connections.
Strict-Transport-Security: max-age=31536000; includeSubDomains
SEO impact
- A site flagged as not fully secure can suffer trust and conversion drops even if rankings hold.
- Active mixed content that breaks page functionality directly harms user experience metrics (bounce, engagement) which feed into ranking systems.
- Mixed content can prevent canonical and indexing signals from being processed cleanly.
Disclaimer: All information contained herein is for informational purposes only. It is not advice or instructional.