Free Mixed Content Checker

What Is Mixed Content?

Mixed content occurs when an initial HTML page is loaded over a secure HTTPS connection, but other resources on the page—such as images, videos, stylesheets, scripts, or iframes—are loaded over an insecure HTTP connection. This creates a security vulnerability because the HTTP resources can be intercepted or modified by attackers, compromising the security of the entire page.

Modern browsers treat mixed content as a serious security issue. When a page served over HTTPS includes HTTP resources, browsers will either block those resources entirely (for active mixed content) or display warnings in the developer console (for passive mixed content). This protection mechanism ensures that users are not exposed to security risks when they see the padlock icon indicating a secure connection.

There are two main categories of mixed content: active mixed content and passive mixed content. Active mixed content includes resources that can interact with the page as a whole, such as scripts, stylesheets, iframes, and XMLHttpRequest objects. Passive mixed content refers to resources that cannot modify the page structure, such as images, audio, and video files. Browsers handle these two categories differently, with active mixed content being blocked by default and passive mixed content often being loaded with warnings.

Understanding the distinction between active and passive mixed content is crucial for diagnosing and fixing security issues on HTTPS websites. While both types present security concerns, active mixed content poses a greater threat because it can be used to execute malicious code, steal sensitive data, or modify the page content in ways that deceive users.

Why Does Mixed Content Matter for SEO?

Mixed content has a direct and significant impact on search engine optimization and overall website performance. Google has explicitly stated that HTTPS is a ranking signal, and sites with mixed content issues fail to provide the secure experience that search engines prioritize. When browsers block mixed content, it can result in broken images, non-functional scripts, and poor user experience—all factors that negatively affect SEO rankings.

From a ranking perspective, Google's algorithms favor sites that provide a secure browsing experience. Sites with mixed content warnings or blocked resources are seen as providing a degraded experience compared to fully secure competitors. This can result in lower rankings, especially in competitive niches where small ranking factors make a significant difference. Additionally, Google Chrome and other major browsers display prominent warnings for sites with mixed content, which can erode user trust and increase bounce rates.

User experience is another critical aspect where mixed content causes problems. When images fail to load due to mixed content blocking, pages appear broken and unprofessional. When scripts are blocked, interactive features may stop working, leading to frustrated users who abandon the site. High bounce rates and low engagement metrics send negative signals to search engines, further harming your SEO performance. Studies show that users are 70% less likely to interact with a site that displays security warnings.

Beyond direct SEO impacts, mixed content issues can prevent you from implementing modern web features that enhance user experience and technical SEO. Features like Service Workers (required for Progressive Web Apps), HTTP/2 push, and certain browser APIs are only available in secure contexts. Sites with mixed content issues cannot take advantage of these performance enhancements, putting them at a competitive disadvantage.

Finally, mixed content issues can complicate analytics and tracking. If your analytics scripts or tracking pixels are loaded over HTTP while your page is HTTPS, browsers may block them, resulting in incomplete data and an inaccurate understanding of user behavior. This makes it harder to optimize your site for conversions and user engagement, indirectly affecting your SEO strategy through poor data-driven decision making.

Active vs Passive Mixed Content in Detail

Active mixed content refers to resources that can directly interact with and modify the content of a web page. These resources have the ability to execute code, change the document object model (DOM), or intercept user interactions. Because of their potential to cause significant security breaches, modern browsers block active mixed content by default. When active mixed content is blocked, the affected resources simply fail to load, which can break functionality on your website.

Passive mixed content consists of resources that are displayed on the page but cannot modify its structure or behavior. While passive mixed content still presents security risks—such as man-in-the-middle attacks that could replace images with malicious content—the risk is considered lower than active mixed content. Browsers historically allowed passive mixed content while displaying warnings, though modern browsers are increasingly moving toward blocking all mixed content by default.

Here is a comprehensive breakdown of resource types and how they are classified:

It's important to note that browser behavior continues to evolve toward stricter security. Chrome, Firefox, and Safari have all announced plans to eventually block all mixed content by default, including passive mixed content. This means that even images and media files loaded over HTTP will be blocked on HTTPS pages in future browser versions. Website owners should proactively address all mixed content issues rather than relying on browsers to show warnings.

The security risk associated with each type of mixed content varies. Active mixed content poses the highest risk because it can be used to inject malicious scripts, steal session cookies, redirect users to phishing sites, or modify page content to deceive users. Passive mixed content, while less dangerous, can still be exploited to track users, replace legitimate content with offensive material, or conduct reconnaissance for future attacks. The best practice is to eliminate all mixed content from your website.

Common Causes of Mixed Content

Mixed content issues typically arise during the migration from HTTP to HTTPS or when integrating third-party resources. Understanding the common causes can help you prevent these issues during development and quickly diagnose them when they occur in production.

Hardcoded HTTP URLs in Content

One of the most common causes of mixed content is hardcoded HTTP URLs in your HTML, CSS, or JavaScript files. This often happens when content creators or developers explicitly specify the protocol in URLs. For example, an image tag might reference http://example.com/image.jpg instead of using protocol-relative URLs or HTTPS. When your site migrates to HTTPS but the content still references HTTP resources, mixed content errors appear.

This issue is particularly prevalent in CMS environments where content has been created over many years. Blog posts, product descriptions, and static pages may contain thousands of hardcoded HTTP references that need to be updated. Database search-and-replace operations can help address this at scale, but must be performed carefully to avoid breaking legitimate HTTP references in text content.

Third-Party Resources Without HTTPS Support

External resources such as CDN-hosted libraries, advertising networks, social media widgets, analytics scripts, and embedded content can cause mixed content issues if the third-party service doesn't support HTTPS. While most major CDNs and services now offer HTTPS endpoints, some older or smaller services may still only serve content over HTTP. When you integrate these resources, they create mixed content warnings on your HTTPS pages.

The solution typically involves either finding an HTTPS-compatible alternative, hosting the resource yourself over HTTPS, or working with the vendor to add HTTPS support. In some cases, you may need to remove the third-party integration entirely if it cannot be secured. Before integrating any third-party service, verify that it supports HTTPS and uses secure delivery methods by default.

Content Management System Configuration

Content management systems like WordPress, Drupal, or custom platforms often store absolute URLs in the database with the protocol included. When you migrate a site from HTTP to HTTPS, the CMS may continue generating HTTP URLs unless you update configuration settings and database values. This affects not only content URLs but also theme references, plugin assets, and system-generated links.

Popular CMS platforms usually offer migration tools or plugins to help update all references from HTTP to HTTPS. For WordPress, plugins like Better Search Replace or Really Simple SSL can automate this process. For custom CMS solutions, you'll need to write database migration scripts that safely update all URL references while preserving data integrity. Always back up your database before performing such migrations.

CDN and Proxy Misconfiguration

Content delivery networks and reverse proxies can introduce mixed content issues if not configured correctly. If your CDN serves some assets over HTTP while your origin serves the HTML over HTTPS, mixed content warnings will appear. This can happen when CDN cache rules, origin fetch protocols, or SSL settings are misconfigured. Some CDNs default to HTTP for certain resource types unless explicitly configured otherwise.

To prevent this, ensure your CDN is configured to serve all resources over HTTPS. Enable HTTP-to-HTTPS redirects at the CDN level, configure SSL certificates for all CDN domains, and verify that origin fetch protocols are set to HTTPS. Many CDNs offer automatic HTTPS rewriting features that can help prevent mixed content issues by rewriting HTTP references to HTTPS on the fly.

Development and Staging Environments

Mixed content issues can be introduced when developers work in HTTP environments but deploy to HTTPS production. If development and staging environments use HTTP while production uses HTTPS, developers may not notice hardcoded HTTP URLs during testing. This can lead to mixed content issues appearing only after deployment to production.

Best practice is to use HTTPS everywhere—development, staging, and production. Tools like mkcert can generate trusted SSL certificates for local development environments, allowing you to test HTTPS behavior locally. This ensures that mixed content issues are caught during development rather than in production. Additionally, implementing automated testing that checks for HTTP references in code can prevent these issues from reaching production.

Dynamically Generated Content

JavaScript code that dynamically generates URLs based on the current page protocol or from API responses can cause mixed content if not handled carefully. If your JavaScript creates image elements, script tags, or stylesheet links using HTTP URLs, these will cause mixed content errors. This is especially common in single-page applications where content is loaded dynamically after the initial page load. Always ensure dynamic URL generation uses HTTPS or protocol-relative URLs when running on secure pages.

How to Find Mixed Content

Identifying mixed content issues requires a combination of browser developer tools, automated scanning tools, and server-side logging. Here are the most effective methods for finding mixed content on your website:

Browser Developer Console

The fastest way to identify mixed content is to open your browser's developer tools (press F12 in Chrome, Firefox, or Edge) and look at the Console tab. Browsers display clear warnings and errors for mixed content, showing you exactly which resources are affected. Chrome displays messages like "Mixed Content: The page was loaded over HTTPS, but requested an insecure resource 'http://example.com/script.js'. This request has been blocked."

The Network tab in developer tools provides even more detail. Filter by "has-response-header:Content-Security-Policy" or look for resources with "http://" in the URL column. Resources that are blocked due to mixed content will show a status of "blocked:mixed-content" or similar. This gives you a comprehensive view of all resources being loaded and which ones are causing security issues.

Content Security Policy Reporting

Content Security Policy (CSP) headers can be configured to report mixed content violations to a specified endpoint. By implementing CSP reporting, you can collect data about mixed content issues that occur for real users across your entire site, not just the pages you manually test. This is invaluable for large websites with thousands of pages where manual testing is impractical.

Configure CSP reporting by adding a report-uri or report-to directive to your Content-Security-Policy header. The browser will send JSON reports to your endpoint whenever a mixed content violation occurs. You can then aggregate these reports to identify patterns and prioritize fixes based on which pages have the most severe or frequent issues.

Automated Scanning Tools

Our free Mixed Content Checker tool crawls your website and identifies all mixed content issues automatically. It detects both active and passive mixed content across all resource types and provides a comprehensive report with severity ratings and fix recommendations. Unlike browser-based testing, automated tools can scan your entire site and identify issues that might not be visible on every page load.

Other popular tools include Google Chrome's Lighthouse (which includes mixed content checks in its security audit), SSL Labs, and specialized website scanners like Screaming Frog SEO Spider. Many of these tools can be integrated into continuous integration pipelines to catch mixed content issues before they reach production. Regular automated scans ensure that new content or code changes don't reintroduce mixed content problems.

Server and CDN Logs

Analyzing server and CDN access logs can reveal patterns in how resources are being requested. Look for requests coming with HTTP referrers pointing to HTTPS pages—these indicate potential mixed content. Log analysis tools can parse millions of requests to identify specific resources that are frequently requested over HTTP when they should be HTTPS.

Set up monitoring and alerting for HTTP requests to resources that should always be served over HTTPS. Many application performance monitoring (APM) tools can track these metrics and alert you when mixed content patterns appear. This proactive approach helps you catch issues before they affect large numbers of users or impact your SEO rankings.

How to Fix Mixed Content Issues

Once you've identified mixed content on your site, there are several approaches to fixing it. The best solution depends on whether you control the resources, the type of content, and your infrastructure setup.

Update URLs to HTTPS

The most straightforward fix is to update all HTTP URLs to HTTPS. Search through your codebase, database, and content for any hardcoded http:// references and replace them with https://. For static content in files, this can be done with find-and-replace operations:

# Find all files with HTTP references
grep -r "http://" .

# Replace in multiple files (be careful with this!)
find . -type f -name "*.html" -exec sed -i 's|http://yourdomain.com|https://yourdomain.com|g' {} +
find . -type f -name "*.js" -exec sed -i 's|http://yourdomain.com|https://yourdomain.com|g' {} +

For database content in WordPress or other CMS platforms, use specialized tools or plugins. In WordPress, the Better Search Replace plugin allows you to safely update URLs in the database. Always create a complete database backup before running search-and-replace operations, and test thoroughly in a staging environment first.

Use Protocol-Relative URLs

Protocol-relative URLs (also called scheme-relative URLs) omit the protocol and start with // instead of http:// or https://. When the browser encounters a protocol-relative URL, it uses the same protocol as the parent page:

<!-- Protocol-relative URL - inherits protocol from page -->
<script src="//cdn.example.com/library.js"></script>
<img src="//example.com/images/photo.jpg" alt="Photo">

<!-- On HTTPS page, browser fetches: https://cdn.example.com/library.js -->
<!-- On HTTP page, browser fetches: http://cdn.example.com/library.js -->

While protocol-relative URLs can be convenient, they have fallen out of favor because they don't work well with modern tooling and can cause issues in certain contexts (like when viewing files locally). The current best practice is to always use explicit HTTPS URLs. Protocol-relative URLs should only be used when you absolutely cannot control the protocol of the page loading the resource.

Implement Content Security Policy Upgrade Directive

The Content-Security-Policy upgrade-insecure-requests directive instructs browsers to automatically upgrade all HTTP resource requests to HTTPS. This provides a quick fix for mixed content across your entire site without manually updating every URL:

<!-- Add to HTML head -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

<!-- Or add as HTTP header (recommended) -->
Content-Security-Policy: upgrade-insecure-requests

When this directive is present, the browser automatically changes all http:// requests to https:// before making them. This works for all resource types including images, scripts, stylesheets, and embedded content. However, this only works if the resources are actually available over HTTPS—if a resource doesn't support HTTPS, it will fail to load. This directive is supported in all modern browsers but should be combined with actual URL updates for maximum compatibility.

Configure Server-Side URL Rewriting

For dynamically generated content, configure your server or application framework to always generate HTTPS URLs. In Apache, you can use mod_substitute to rewrite HTTP URLs to HTTPS in HTML output:

# Apache .htaccess or httpd.conf
<IfModule mod_substitute.c>
    # Enable output filtering
    AddOutputFilterByType SUBSTITUTE text/html

    # Replace HTTP URLs with HTTPS for your domain
    Substitute "s|http://yourdomain.com|https://yourdomain.com|ni"

    # Replace HTTP URLs with HTTPS for CDN
    Substitute "s|http://cdn.yourdomain.com|https://cdn.yourdomain.com|ni"
</IfModule>

For NGINX, use the substitution module:

# NGINX configuration
location / {
    # Enable substitution
    sub_filter 'http://yourdomain.com' 'https://yourdomain.com';
    sub_filter 'http://cdn.yourdomain.com' 'https://cdn.yourdomain.com';
    sub_filter_once off;
    sub_filter_types text/html text/css application/javascript;
}

Server-side URL rewriting is a powerful technique but should be used as a temporary measure while you fix the underlying content. Rewriting adds processing overhead and can miss URLs in certain contexts like JSON responses or JavaScript-generated content. The best long-term solution is to fix URLs at the source.

Host Third-Party Resources Locally

If a third-party resource doesn't support HTTPS, consider downloading it and hosting it on your own HTTPS-enabled server or CDN. This gives you full control over the resource delivery and eliminates the third-party dependency. For example, if you're using a font or JavaScript library from an HTTP-only CDN, download the files and serve them from your own domain:

<!-- Before: Mixed content from HTTP CDN -->
<script src="http://insecure-cdn.com/library.js"></script>

<!-- After: Self-hosted over HTTPS -->
<script src="https://yourdomain.com/js/library.js"></script>

When self-hosting third-party resources, remember to periodically check for updates and security patches. Set up a process to regularly update these files to ensure you benefit from bug fixes and security improvements. Document which resources are self-hosted and where they originate from to make future maintenance easier.

Content-Security-Policy for Mixed Content

Content Security Policy (CSP) is a powerful HTTP header that helps prevent mixed content and other security vulnerabilities. Beyond just fixing mixed content, CSP provides a comprehensive security framework that protects against cross-site scripting (XSS), clickjacking, and other injection attacks.

Upgrade Insecure Requests Directive

The upgrade-insecure-requests directive is specifically designed to handle mixed content by automatically upgrading all HTTP requests to HTTPS:

# HTTP Header (add to server configuration)
Content-Security-Policy: upgrade-insecure-requests;

# Or in HTML meta tag
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

This directive tells compliant browsers to treat all HTTP URLs as if they were HTTPS. When the browser encounters an HTTP resource request, it automatically rewrites it to HTTPS before making the network request. This provides broad protection against mixed content without requiring you to update every URL manually. However, it only works if the resources are actually available over HTTPS.

Block All Mixed Content Directive

The block-all-mixed-content directive takes a stricter approach by blocking all mixed content, including passive mixed content that browsers might otherwise allow with warnings:

# HTTP Header
Content-Security-Policy: block-all-mixed-content;

# Or in HTML
<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

This directive is useful when migrating to HTTPS to ensure that no mixed content slips through, even in older browsers that might allow passive mixed content. It provides stronger security guarantees but will break any resources that haven't been updated to HTTPS. Use this in combination with thorough testing to ensure all resources are accessible over HTTPS before enabling it in production.

Comprehensive CSP Configuration

A comprehensive CSP header can specify exactly which protocols and sources are allowed for each resource type, providing granular control over mixed content and other security issues:

# Example comprehensive CSP header
Content-Security-Policy:
    default-src https: 'self';
    script-src https: 'self' 'unsafe-inline' https://trusted-cdn.com;
    style-src https: 'self' 'unsafe-inline';
    img-src https: 'self' data:;
    font-src https: 'self';
    connect-src https: 'self';
    media-src https: 'self';
    object-src 'none';
    frame-src https: 'self';
    upgrade-insecure-requests;
    block-all-mixed-content;

This policy enforces HTTPS for all resource types while allowing specific trusted sources. The default-src https: 'self' directive ensures all resources default to HTTPS from the same origin unless explicitly allowed otherwise. Each directive can be fine-tuned to match your specific needs.

CSP Reporting

CSP supports reporting violations to a specified endpoint, allowing you to monitor mixed content issues in production without blocking resources. Use report-only mode during initial deployment to identify issues without breaking functionality:

# Report-only mode (logs violations without blocking)
Content-Security-Policy-Report-Only:
    default-src https:;
    upgrade-insecure-requests;
    report-uri https://yourdomain.com/csp-report;

# Production mode with reporting
Content-Security-Policy:
    default-src https:;
    upgrade-insecure-requests;
    block-all-mixed-content;
    report-uri https://yourdomain.com/csp-report;

Browsers send JSON reports to your report-uri endpoint whenever a CSP violation occurs. You can process these reports to identify patterns, prioritize fixes, and monitor for new violations over time. Many third-party services like Report URI and Sentry provide CSP reporting infrastructure if you don't want to build your own endpoint.

Best Practices for HTTPS Security

Eliminating mixed content is just one aspect of comprehensive HTTPS security. Follow these best practices to ensure your site provides maximum security for users:

# Strict-Transport-Security header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

<script
  src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
  crossorigin="anonymous">
</script>

Frequently Asked Questions