Back to Articles
Web Security
Updated Dec 13, 2025

Fixing Mixed Content on HTTPS Pages: A Complete Guide to a Secure Website

You've successfully migrated your website to HTTPS—a crucial step for security, SEO, and user trust. But then you see it: a broken image, a missing stylesheet, or worse, a browser warning like "Your connection is not fully secure." If this sounds familiar, you're likely battling mixed content.

Mixed content occurs when a webpage loaded over secure HTTPS attempts to load some resources (images, scripts, CSS, iframes) over insecure HTTP. It's frustrating for users and, more importantly, it creates security vulnerabilities that can compromise your entire site.

This guide is your comprehensive roadmap to identifying, understanding, and eliminating mixed content. We'll walk you through step-by-step solutions, from quick code fixes to advanced server-side strategies, ensuring your HTTPS site works perfectly and stays secure.

Table of Contents

Understanding Mixed Content: Why It's a Problem

Mixed content isn't just an aesthetic annoyance; it's a genuine security risk. When an HTTPS page loads HTTP resources:

  1. Security Risk: Insecure HTTP resources can be intercepted and modified by attackers in transit. This means an attacker could inject malicious scripts into your page (even if the page itself is HTTPS) or swap out images for phishing content.
  2. User Trust Erosion: Browsers display security warnings or broken padlock icons, which actively deter users and undermine confidence in your site.
  3. Functionality Issues: Browsers often automatically block "active" mixed content (scripts, stylesheets, iframes) to protect users, which can break critical parts of your website.

Types of Mixed Content

Browsers distinguish between two types based on their potential impact:

  • Active Mixed Content: These are resources that can interact with the page or affect its behavior, like <script>, <link rel="stylesheet">, <iframe>, XMLHttpRequest (AJAX requests), or <object> tags. Browsers typically block active mixed content by default.
  • Passive Mixed Content: These are resources that don't interact with the page's global environment, such as <img>, <audio>, <video>, or <source> elements. Browsers usually display warnings for passive mixed content but may still render it.

Your First Line of Defense: Identifying Mixed Content

You can't fix what you can't find. Here's how to pinpoint mixed content issues.

1. Browser Developer Tools (Your Best Friend)

This is the fastest and most effective way to identify mixed content on a page-by-page basis.

  • Open DevTools: Press F12 (Windows/Linux) or Cmd + Option + I (macOS), or right-click anywhere on your page and select "Inspect."
  • Navigate to the Console Tab: Look for messages like Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource 'http://example.com/image.jpg'. This request has been blocked/warned.
  • Check the Network Tab: Reload the page with DevTools open. Filter by "Blocked Requests" or "Blocked by Content Security Policy" if you have one. Insecure HTTP requests will often show up here.

2. Automated Detection Tools

For larger sites, manual checks are insufficient.

  • Online Scanners: Websites like WhyNoPadlock.com or SSL Labs SSL Test can scan your page and report mixed content.
  • Command Line Tools (Basic Check):
    # Quickly grep for HTTP links in a webpage's source
    curl -s https://your-site.com | grep -i "http://"
    

3. Codebase Analysis (Search & Replace)

This is a brute-force but effective method for hardcoded HTTP references.

  • Search your codebase for http://:
    # Search in HTML, CSS, and JavaScript files
    grep -r "http://" your_project_directory/
    
    Pay special attention to URLs within <img src="...">, <script src="...">, <link href="...">, @import url(...) in CSS, and fetch('http://...') in JavaScript.

Common Sources of Mixed Content (And Where to Look)

Mixed content often creeps in from predictable places.

  • Hardcoded HTTP URLs in Templates/Code: Developers might directly link to http:// resources.
  • Content Management Systems (CMS) & Databases: Images or links inserted by users (or even old themes/plugins) might be stored with http:// in the database.
  • Third-Party Integrations: Embedded widgets, analytics scripts, social media buttons, or advertising snippets from external providers might still use HTTP.
  • Dynamic Content: User-generated content (comments, forum posts) that includes http:// links.
  • CSS Files: Background images or fonts referenced with url(http://...).
  • JavaScript: Dynamically loaded scripts or AJAX requests to http:// endpoints.

Comprehensive Fix Strategies: Eradicating Mixed Content

Once you've identified the source, here's how to eliminate mixed content.

1. The Golden Rule: Use HTTPS Directly

The best and most permanent solution is to update all http:// URLs to https://.

  • HTML, CSS, JavaScript: Manually change http:// to https:// for all internal and external resources where HTTPS is supported.
  • CMS & Database Updates: Use search-and-replace tools or SQL queries to update URLs in your database.
    -- WordPress Example: Update all HTTP URLs to HTTPS in post content
    UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
    UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://www.yourdomain.com', 'https://www.yourdomain.com');
    -- Repeat for other relevant tables like wp_postmeta, wp_options
    
  • Third-Party Services: Always use the HTTPS version of third-party scripts and assets. If a service doesn't offer HTTPS, consider finding an alternative provider.

2. Protocol-Relative URLs (Use with Caution)

Protocol-relative URLs like //example.com/image.jpg automatically use the same protocol as the page they are on. If the page is HTTPS, the resource loads over HTTPS; if HTTP, it loads over HTTP.

Why to use sparingly: While they can help prevent mixed content, they don't force HTTPS. If your site reverts to HTTP for any reason, all resources will also load insecurely. It's generally better to explicitly use https://.

3. Content Security Policy (CSP) with upgrade-insecure-requests

This CSP directive instructs the browser to automatically try to upgrade any http:// requests to https:// before making the request. If the resource isn't available over HTTPS, it won't load. This is an excellent mitigation during cleanup or for third-party content you can't directly control.

Content-Security-Policy: upgrade-insecure-requests;

You can implement this at your web server, CDN, or application level.

# Nginx Example: Add CSP header
add_header Content-Security-Policy "upgrade-insecure-requests;" always;

(For a comprehensive understanding of CSP, refer to our Content Security Policy Guide).

4. Server-Side URL Rewriting

Your web server can rewrite http:// requests to https:// before sending content to the browser. This is useful for content you cannot easily change in your codebase or database.

# Nginx Example: Proxy rewrite for specific HTTP content
location / {
    sub_filter 'http://cdn.old-domain.com' 'https://cdn.old-domain.com';
    sub_filter_once off; # Apply to all occurrences
    # ... other configurations
}

5. CDN and Edge Solutions

Many CDNs offer features to automatically rewrite HTTP assets to HTTPS.

  • Cloudflare: Enable "Automatic HTTPS Rewrites."
  • AWS CloudFront: Configure "Viewer Protocol Policy" to "Redirect HTTP to HTTPS" and use Lambda@Edge functions for more granular rewriting.
  • Azure Front Door: Use routing rules to enforce HTTPS and potentially rewrite subresource URLs.

6. Application-Level JavaScript Rewriting (Last Resort)

While not ideal (as it runs client-side after initial page load), JavaScript can dynamically rewrite URLs. Use this only if server-side or CSP solutions are not feasible.

// Example: Upgrade all http:// image sources to https://
document.addEventListener('DOMContentLoaded', () => {
  document.querySelectorAll('img[src^="http://"]').forEach(img => {
    img.src = img.src.replace('http://', 'https://');
  });
});

Continuous Monitoring & Prevention

Fixing mixed content is an ongoing effort, especially with dynamic sites and user-generated content.

1. Automated Checks in CI/CD

Integrate mixed content checks into your Continuous Integration pipeline to catch new issues before they hit production.

// Example: Playwright test to fail build on mixed content warnings
import { chromium } from 'playwright';
test('should not have mixed content warnings', async ({ page }) => {
  const mixedContentErrors = [];
  page.on('console', msg => {
    if (msg.type() === 'warning' && msg.text().includes('Mixed Content')) {
      mixedContentErrors.push(msg.text());
    }
  });
  await page.goto('https://your-site.com'); // Test your actual URL
  await page.waitForLoadState('networkidle');
  expect(mixedContentErrors).toHaveLength(0); // Fails if any mixed content is found
});

2. Regular Scanning

Run regular scans of your website with tools that specifically check for mixed content.

  • Barrion's Dashboard: Offers continuous scanning for mixed content and other security issues, providing alerts if new problems arise.
  • Online Mixed Content Scanners: Re-run these periodically.

3. Developer Awareness

Educate your team to always use https:// when linking to external resources and to use relative paths for internal assets.

Conclusion: A Fully Secure HTTPS Experience

Mixed content issues are a common headache, but with a systematic approach, they are entirely fixable. The key is to:

  1. Identify Sources: Use browser DevTools and codebase searches.
  2. Prioritize Direct HTTPS: Change all http:// links to https:// in your code, configurations, and database.
  3. Leverage CSP: Implement upgrade-insecure-requests as a powerful mitigation.
  4. Automate: Integrate checks into your CI/CD and use continuous monitoring.

By diligently cleaning up mixed content, you not only eliminate security risks but also restore full user trust and ensure your website delivers the secure experience it promises.


Ready to Clean Up Your Website?

Start your free security scan with Barrion today to get immediate insights into any mixed content issues and other vulnerabilities on your site.

For detailed analysis and continuous monitoring of your web application security, visit the Barrion dashboard.

Frequently asked questions

Q: Why does mixed content appear after enabling HTTPS?

A: Legacy "http://" references in templates, CSS, or third-party embeds often remain after the HTTPS cutover. Update these to HTTPS or update to modern packages.

Q: Is upgrade-insecure-requests a permanent fix?

A: No. It’s a temporary bridge. Fix the sources to avoid surprises and maintain long-term security.

Q: Can my CDN fix mixed content for me?

A: CDN rewrites can help, but aim to correct code and content. Use rewrites only as a safety net.

Trusted by IT Professionals

IT professionals worldwide trust Barrion for comprehensive vulnerability detection.
Get detailed security reports with actionable fixes in under 60 seconds.

Barrion logo iconBarrion

Barrion delivers automated security scans and real-time monitoring to keep your applications secure.

Contact Us

Have questions or need assistance? Reach out to our team for support.

© 2025 Barrion - All Rights Reserved.