What Is Mixed Content and How Do You Fix It on an HTTPS Website?
Mixed content happens when a web page is loaded securely over HTTPS but still requests one or more resources over insecure HTTP.
For example, the page itself may use:
https://example.com
while loading an image from:
http://cdn.example.com/image.jpg
or a script from:
http://example.net/script.js
The main document is protected by TLS, but some of the resources used by the page are not.
This creates an inconsistent security state and can cause browsers to block resources, display warnings, or prevent the page from behaving as expected.
Mixed content is especially common after a website moves from HTTP to HTTPS and old links remain inside themes, templates, databases, stylesheets, or application code.
What Does Mixed Content Mean?
A modern HTTPS page should ideally load its resources through secure URLs.
A clean page might use:
https://example.com
https://example.com/style.css
https://example.com/app.js
https://cdn.example.com/logo.svg
A mixed-content page might instead contain:
https://example.com
http://example.com/style.css
http://cdn.example.com/logo.svg
The browser now has a secure top-level page that depends on insecure subresources.
Why Is Mixed Content a Security Problem?
HTTPS protects traffic between the browser and the server using TLS.
HTTP does not provide the same transport protection.
If an HTTPS page loads a resource through HTTP, someone capable of modifying network traffic may be able to alter that insecure resource before it reaches the browser.
The impact depends on the type of resource.
An insecure image is undesirable, but an insecure JavaScript file can be much more serious because JavaScript can modify the page, read data, send requests, or change user-visible content.
Passive vs Active Mixed Content
Mixed content has historically been divided into different categories based on how dangerous the insecure resource is.
Passive mixed content
This can include resources such as:
- Images
- Audio
- Video
These resources normally display content rather than execute code.
Active mixed content
This can include:
- JavaScript
- Stylesheets
- Frames
- Some embedded resources
Active content can directly influence how the page behaves, so browsers generally treat it more strictly.
How Do Browsers Handle Mixed Content?
Modern browsers may block insecure resources automatically.
Behavior depends on the resource type and browser implementation.
For example, a browser may:
- Block an HTTP script completely.
- Prevent an insecure iframe from loading.
- Automatically upgrade certain HTTP image requests to HTTPS.
- Display a warning in developer tools.
The safest approach is not to depend on browser auto-upgrade behavior. Fix the URLs at the website level.
What Does a Mixed Content Error Look Like?
Browser developer tools may show a message similar to:
Mixed Content:
The page at 'https://example.com'
was loaded over HTTPS,
but requested an insecure resource
'http://example.com/script.js'.
The exact wording varies, but the important details are:
- The main page uses HTTPS.
- A resource uses HTTP.
- The browser may block or upgrade the request.
Why Does a Website Still Show Security Warnings After Installing SSL?
Installing a valid certificate only secures connections that actually use HTTPS.
If the HTML still references:
http://
resources, the browser may still detect insecure content.
This is why switching a website to HTTPS involves more than installing a certificate.
The site also needs to update internal resource URLs.
Common Sources of Mixed Content
Images
Old image links are one of the most common causes:
<img src="http://example.com/uploads/photo.jpg">
JavaScript
<script src="http://example.net/app.js"></script>
Stylesheets
<link rel="stylesheet" href="http://example.com/style.css">
Fonts
Custom font files can also be referenced through HTTP.
iframes
<iframe src="http://example.net/widget"></iframe>
Background images in CSS
background-image: url('http://example.com/bg.jpg');
Third-party widgets
Older analytics tools, advertising scripts, social widgets, or chat systems may still use HTTP URLs.
Mixed Content After an HTTP to HTTPS Migration
This is one of the most common scenarios.
Before migration, a site may contain thousands of absolute URLs like:
http://example.com/uploads/image.jpg
After the main website changes to:
https://example.com
those stored URLs may remain unchanged.
The website loads over HTTPS, but its old resources continue using HTTP.
Absolute URLs vs Relative URLs
An absolute URL includes the complete protocol and hostname:
http://example.com/images/logo.png
A relative URL may be:
/images/logo.png
When the page itself is loaded over HTTPS, the relative URL is normally requested through the same HTTPS origin.
For same-site resources, relative paths can reduce the chance of hardcoding an obsolete protocol.
Should You Replace HTTP With HTTPS Everywhere?
Only when the destination actually supports HTTPS.
Changing:
http://third-party.example/script.js
to:
https://third-party.example/script.js
works only if that third-party server supports HTTPS correctly.
If it does not, the resource will fail to load.
In that case, you may need to:
- Replace the provider.
- Host the resource locally when licensing allows it.
- Remove the dependency.
How to Find Mixed Content
The browser's developer tools are usually the fastest place to start.
Open the affected page and check:
- Console
- Network panel
- Security information
Search for requests beginning with:
http://
on a page loaded through HTTPS.
Why Checking the HTML Source Is Not Always Enough
Some insecure resources may not appear directly in the original HTML.
They can be added by:
- JavaScript
- CSS files
- Plugins
- Third-party widgets
- Application APIs
For that reason, inspect actual network requests made by the browser, not only the page source.
Mixed Content in CSS
A stylesheet loaded securely can still reference insecure assets.
For example:
https://example.com/style.css
may contain:
.hero {
background-image: url('http://example.com/hero.jpg');
}
The page may appear mostly correct while the browser still reports mixed content.
Mixed Content in JavaScript
JavaScript can dynamically generate URLs.
For example:
const api = 'http://api.example.com/data';
Even if the HTML contains no visible HTTP resource, the script may create one after the page loads.
Mixed Content in API Requests
A secure web application may call an API using:
http://api.example.com
Modern browsers can block this request.
The API should normally be available through:
https://api.example.com
with a valid certificate.
Mixed Content in Forms
A page may load securely but submit form data to an insecure destination.
For example:
<form action="http://example.com/login">
This is especially serious for forms containing:
- Usernames
- Passwords
- Personal information
- Payment data
The form destination should use HTTPS.
Mixed Content in WordPress
WordPress sites often encounter mixed-content problems after HTTPS migration because URLs can be stored in the database.
Common locations include:
- Post content
- Theme settings
- Page builder data
- Widget configuration
- Media URLs
- Plugin settings
The WordPress Address and Site Address should also use the correct HTTPS URL.
Why Search-and-Replace Must Be Done Carefully
Bulk replacing:
http://example.com
with:
https://example.com
can solve many internal links, but database operations should be performed carefully.
Some applications store serialized or structured data that can be damaged by unsafe text replacement.
Use tools designed for the relevant application or database format.
Mixed Content in Laravel and Custom Applications
Custom applications can generate HTTP URLs if the application does not correctly detect that the public request uses HTTPS.
This is common when the architecture is:
User
↓ HTTPS
Reverse Proxy
↓ HTTP
Application
The application sees the internal HTTP connection and may generate:
http://example.com/assets/app.css
even though the visitor connected using HTTPS.
Reverse Proxy Configuration and Mixed Content
When a reverse proxy terminates TLS, the application needs accurate information about the original protocol.
Proxy-related headers may be used to tell the backend that the original request was secure.
If proxy trust is configured incorrectly, the application can generate insecure URLs.
Mixed Content Behind a CDN
A CDN can serve the public website over HTTPS while the application still generates HTTP asset links.
The visible path may be:
Visitor
↓ HTTPS
CDN
↓
Origin
The CDN does not automatically rewrite every HTTP URL stored inside the page.
The application should generate secure URLs itself.
Can a CDN Automatically Fix Mixed Content?
Some platforms offer automatic HTTPS rewriting features.
These may convert certain HTTP resource URLs to HTTPS when the destination supports it.
This can be useful as a temporary compatibility feature, but it is better to correct the source URLs in the application when possible.
What Is Upgrade-Insecure-Requests?
Content Security Policy includes a directive called:
upgrade-insecure-requests
It can instruct the browser to treat insecure resource URLs as though they had been requested over HTTPS.
For example:
Content-Security-Policy: upgrade-insecure-requests
An HTTP resource reference may then be upgraded to HTTPS automatically.
Does upgrade-insecure-requests Fix Everything?
No.
The destination still needs to support HTTPS.
If:
http://old.example.net/resource.js
is upgraded to:
https://old.example.net/resource.js
but that server has no HTTPS service, the resource fails.
The directive is useful but should not replace proper URL cleanup.
What Is block-all-mixed-content?
Content Security Policy has also provided mechanisms for blocking mixed content.
The broader goal is to prevent insecure subresources from weakening an HTTPS page.
Modern browsers already block many dangerous mixed-content requests by default, so application owners should focus on removing the underlying insecure references.
Mixed Content and HSTS
HSTS forces HTTPS for hostnames covered by the policy.
If a page references:
http://static.example.com/image.jpg
and static.example.com is covered by an HSTS policy, the browser may upgrade that request to HTTPS.
However, HSTS should not be treated as a substitute for fixing application URLs.
Mixed Content and includeSubDomains
An HSTS policy containing:
includeSubDomains
can cause browser requests to subdomains to use HTTPS.
This can hide some old HTTP references, but only if those subdomains support HTTPS correctly.
A broken HTTPS subdomain will still fail.
Mixed Content and SSL Certificates
Every HTTPS resource needs a valid TLS endpoint.
Suppose the main website is:
https://example.com
and an asset is moved to:
https://cdn.example.com
The CDN hostname also needs a valid certificate covering:
cdn.example.com
Otherwise, the browser trades a mixed-content problem for a certificate problem.
Mixed Content and Certificate Name Mismatch
Changing an asset from HTTP to HTTPS is not enough if its certificate is wrong.
For example:
https://assets.example.com
must present a certificate valid for:
assets.example.com
Mixed Content and Expired Certificates
An HTTPS resource with an expired certificate may be blocked even though it is no longer technically mixed content.
Each secure dependency must have a valid TLS configuration.
Mixed Content and Third-Party Services
External services are a frequent source of old HTTP URLs.
Examples include:
- Tracking pixels
- Advertising scripts
- Chat widgets
- Video embeds
- Maps
- Fonts
- Legacy APIs
When migrating to HTTPS, audit all third-party dependencies.
What If a Third-Party Service Does Not Support HTTPS?
For a modern production website, continuing to load an insecure third-party resource is generally not a good long-term solution.
Consider:
- Removing the integration.
- Replacing it with a provider that supports HTTPS.
- Hosting an allowed static resource locally.
Mixed Content and WebSockets
Secure HTTPS pages should generally use secure WebSocket connections:
wss://
instead of:
ws://
An application using insecure WebSockets from a secure page may encounter browser security restrictions.
Mixed Content and Downloads
Browsers may also treat downloads initiated from secure pages differently when the file is delivered over HTTP.
Security behavior has become stricter over time, especially for potentially dangerous file types.
Downloads linked from secure pages should ideally be available through HTTPS as well.
Mixed Content and Redirects
A URL can appear secure in the page source but redirect to HTTP.
For example:
https://cdn.example.com/file.js
↓
302 Redirect
↓
http://old-cdn.example.com/file.js
The final destination becomes insecure.
Check the complete redirect chain when an HTTPS-looking URL still produces mixed-content warnings.
How to Fix Mixed Content Step by Step
Step 1: Confirm the page uses HTTPS
Start with the exact page:
https://example.com/page
Step 2: Open browser developer tools
Check the Console and Network panels.
Step 3: Identify insecure URLs
Look for:
http://
requests.
Step 4: Determine where each URL comes from
It may be generated by:
- HTML
- CSS
- JavaScript
- Database content
- A plugin
- A third-party service
Step 5: Check whether HTTPS is available
Open the HTTPS version of the resource directly.
Step 6: Update the URL
Change the source configuration to use HTTPS or a safe relative path.
Step 7: Clear application and CDN caches
An older page version may still contain HTTP URLs.
Step 8: Test again
Reload the page and confirm that no insecure requests remain.
Example: Fixing an Insecure Image
Before:
<img src="http://example.com/images/photo.jpg">
After:
<img src="https://example.com/images/photo.jpg">
or:
<img src="/images/photo.jpg">
Example: Fixing an Insecure Script
Before:
<script src="http://cdn.example.com/app.js"></script>
After:
<script src="https://cdn.example.com/app.js"></script>
Only do this after confirming the HTTPS endpoint works and is trusted.
Example: Fixing an API URL
Before:
fetch('http://api.example.com/data')
After:
fetch('https://api.example.com/data')
The API server also needs a valid certificate and correct CORS configuration where applicable.
Example: Fixing CSS Background Images
Before:
.banner {
background: url('http://example.com/banner.jpg');
}
After:
.banner {
background: url('/banner.jpg');
}
Why Mixed Content Can Appear Only on Certain Pages
Different pages can load different resources.
For example:
Homepage:
All HTTPS
Old blog post:
HTTP image
Contact page:
HTTP map widget
The website may therefore appear secure on most pages while a few URLs still produce warnings.
Why Mixed Content Can Appear Only After Login
Authenticated pages may use additional:
- APIs
- User avatars
- Dashboards
- Third-party widgets
Those resources may contain old HTTP references that are invisible on public pages.
Why Mixed Content Can Appear Only on Mobile
Responsive websites can load different assets depending on device size or platform.
For example, the mobile template may contain:
http://example.com/mobile-banner.jpg
while the desktop template uses the correct HTTPS asset.
Why Mixed Content Can Appear After Enabling a CDN
A CDN configuration change can alter generated URLs.
The application might produce:
http://cdn.example.com/assets/style.css
because the CDN base URL was configured before HTTPS was enabled.
Update the application's CDN URL to HTTPS.
Why Mixed Content Can Appear After a Domain Change
A site moved from:
old-example.com
to:
new-example.com
may still reference old HTTP resources:
http://old-example.com/uploads/photo.jpg
Review historical content and application configuration.
Mixed Content and Browser Caching
After fixing the source, a browser or CDN may still have an older page cached.
If developer tools show the old URL, check:
- Browser cache
- Page cache
- Reverse proxy cache
- CDN cache
Confirm the current HTML or script actually contains the corrected URL.
Mixed Content and Service Workers
Progressive web applications can use service workers that cache page assets.
An older service worker may continue serving resources or HTML containing HTTP URLs after the server has been fixed.
Check service-worker caches when problems persist unexpectedly.
Can DNS Cause Mixed Content?
DNS does not normally create mixed content directly because mixed content is determined by the URL protocol used by the page.
However, DNS can still affect whether the secure replacement works.
For example:
https://cdn.example.com
must resolve to a server that supports HTTPS and presents the correct certificate.
Does an SSL Certificate Automatically Fix Mixed Content?
No.
An SSL certificate secures the hostname where it is installed.
It does not automatically rewrite:
http://
links inside your HTML, CSS, JavaScript, or database.
Does HSTS Automatically Fix Mixed Content?
Not reliably.
HSTS can upgrade requests to hostnames covered by the HSTS policy, but it does not guarantee that every third-party resource supports HTTPS.
Fix the actual application references.
Should You Use Protocol-Relative URLs?
Older websites sometimes used URLs like:
//cdn.example.com/app.js
The browser would choose HTTP or HTTPS based on the current page.
On modern websites that are permanently HTTPS, explicit HTTPS URLs or relative same-origin paths are usually clearer.
Mixed Content and SEO
Mixed content is primarily a security and functionality issue.
Blocked scripts, stylesheets, or images can also affect how a page renders and functions for users and crawlers.
A well-maintained HTTPS site should avoid insecure dependencies.
Mixed Content and Ad Networks
Advertising scripts should be loaded through HTTPS on HTTPS websites.
Modern ad platforms generally support secure delivery.
Legacy ad code using HTTP should be updated rather than kept as an insecure dependency.
Mixed Content and Analytics
Analytics scripts and tracking pixels can also cause mixed content if old HTTP snippets remain in the site.
Review historical templates and tag-management configurations after migrating to HTTPS.
Mixed Content and Embedded Media
Video players, maps, document viewers, and other embeds should use secure endpoints.
Old embed codes copied years ago may still contain:
http://
URLs even when the provider now supports HTTPS.
How to Prevent Mixed Content
Good practices include:
- Use HTTPS for every public dependency.
- Prefer relative URLs for same-origin assets when appropriate.
- Avoid hardcoded HTTP links.
- Audit third-party integrations.
- Test HTTPS before production deployment.
- Use browser developer tools during QA.
- Review old content after migrations.
- Monitor CDN configuration.
A Practical Mixed Content Checklist
- Open the affected HTTPS page.
- Check the browser Console.
- Check the Network panel.
- Find HTTP requests.
- Identify which code or content generates each URL.
- Verify an HTTPS version exists.
- Replace the insecure URL.
- Check CSS files.
- Check JavaScript-generated requests.
- Check forms.
- Check APIs.
- Check third-party widgets.
- Check CDN settings.
- Clear relevant caches.
- Reload and retest the page.
How DomainScan Can Help
Mixed content is mainly an application-level issue, but DomainScan tools can help verify that the secure infrastructure behind replacement URLs is working correctly.
SSL Checker
Use it to confirm that a hostname such as:
cdn.example.com
has a valid certificate before changing an asset URL from HTTP to HTTPS.
DNS Lookup
Use it to verify that asset, API, or CDN hostnames resolve to the intended infrastructure.
DNS Propagation Check
Use it when a newly enabled HTTPS hostname is still resolving differently across networks.
Open Ports Lookup
Use it to help confirm that the expected HTTPS endpoint is reachable.
Frequently Asked Questions
What is mixed content?
Mixed content occurs when an HTTPS page loads one or more resources through insecure HTTP.
Why is mixed content bad?
Insecure resources can weaken the protection provided by HTTPS and may be modified by someone capable of interfering with network traffic.
Can mixed content make a website show Not Secure?
Yes. Browsers may display warnings, reduce the page's security status, or block insecure resources.
How do I find mixed content?
Open browser developer tools and inspect Console and Network messages for HTTP resources loaded from an HTTPS page.
How do I fix mixed content?
Replace insecure HTTP resource URLs with working HTTPS URLs or safe relative URLs.
Can I just change every http:// to https://?
Only if each destination supports HTTPS correctly. Otherwise, the resource may stop working.
Does installing SSL fix mixed content?
No. SSL installation does not automatically update hardcoded HTTP URLs.
Can a CSS file cause mixed content?
Yes. CSS may reference HTTP images, fonts, or other resources.
Can JavaScript cause mixed content?
Yes. Scripts can dynamically request HTTP APIs, images, or other resources.
Can a third-party widget cause mixed content?
Yes. Old widgets, analytics code, ads, maps, and embeds may contain insecure URLs.
Does HSTS fix mixed content?
It can upgrade certain requests to HSTS-covered hosts, but it should not replace fixing insecure URLs in the website itself.
Does mixed content affect only images?
No. It can involve scripts, stylesheets, fonts, frames, API calls, forms, media, and other resources.
Final Thoughts
Mixed content is one of the most common problems encountered after moving a website from HTTP to HTTPS.
The website may have a valid certificate and a working secure connection while old HTTP links remain hidden inside templates, stylesheets, scripts, databases, or third-party integrations.
The most reliable way to fix the problem is to identify each insecure request, determine where that URL is generated, and replace it with a working HTTPS endpoint or an appropriate same-origin relative path.
Do not rely only on browser auto-upgrades, HSTS, or CDN rewriting. Correcting the source configuration produces a cleaner and more predictable HTTPS deployment.
Use DomainScan SSL Checker to verify certificates on asset and API hostnames, DNS Lookup to confirm that those hostnames resolve correctly, and DNS Propagation Check when new secure endpoints are still returning inconsistent results across networks.
