Cybersecurity / Networking

HTTPS Mixed Content Warning, How to Resolve

A mixed content warning means a page served over HTTPS is loading at least one resource (an image, script, stylesheet, or API call) over plain HTTP — browsers flag or actively block this because it undermines the security guarantee HTTPS is supposed to provide for the entire page.

The Problem

Your site loads over HTTPS, but the browser console shows warnings, and sometimes resources fail to load entirely:

Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but 
requested an insecure resource 'http://example.com/script.js'. This request 
has been blocked; the content must be served over HTTPS.

Depending on the type of resource and the browser, this might just be a warning (for some passive content like images) or an outright block (for active content like scripts, which browsers treat as more dangerous to load insecurely).

Why It Happens

This happens whenever any resource on an HTTPS page is explicitly referenced with an http:// URL rather than https:// or a protocol-relative path. Common sources:

  • Hardcoded http:// URLs in HTML, CSS, or JavaScript that were written before the site moved to HTTPS, and never updated during the migration
  • Third-party embeds, widgets, or ad scripts that themselves reference HTTP resources internally, outside your direct control over their own code
  • User-generated content (in a CMS, a forum, a comment section) containing HTTP image or link URLs, submitted by users at a time when either the content itself or the site was still on HTTP
  • A CDN or asset URL configuration that generates HTTP links by default, unless explicitly configured to use HTTPS

The Fix

First, identify every instance of mixed content by checking the browser console on each page, since warnings/errors there list the exact insecure URLs being requested. For a more systematic audit across an entire site, use a dedicated mixed content scanning tool rather than manually clicking through every page.

For resources you control directly, simply update the URL to use HTTPS:

<!-- Before -->
<script src="http://example.com/script.js"></script>

<!-- After -->
<script src="https://example.com/script.js"></script>

For resources that should always match whatever protocol the current page is using (useful for URLs that might be embedded in contexts using either protocol, though this is less common now that HTTPS is close to universal), use a protocol-relative URL instead of hardcoding either scheme:

<script src="//example.com/script.js"></script>

For user-generated content containing HTTP URLs submitted before your site moved to HTTPS, either run a one-time database migration to rewrite stored HTTP URLs to HTTPS where the resource is confirmed to support it, or apply the fix dynamically at render time:

function ensureHttps(url) {
  return url.replace(/^http:\/\//i, 'https://');
}

Be cautious with this approach for third-party URLs you don't control — forcing HTTPS on a URL that doesn't actually support it results in a broken resource rather than a fixed one, so confirm the target genuinely supports HTTPS before blanket-rewriting URLs pointing to it.

For third-party embeds or widgets you don't directly control that reference HTTP internally, check whether the provider offers an HTTPS-compatible embed code or script URL — most modern services do, and using their updated embed snippet resolves the issue without needing to work around their code directly.

As a stronger, more systematic enforcement mechanism, add a Content Security Policy directive that automatically upgrades any insecure request to HTTPS, catching cases you might have missed manually:

Content-Security-Policy: upgrade-insecure-requests

This tells the browser to automatically rewrite any http:// resource request on the page to https:// before making it, which handles most mixed content scenarios automatically as a safety net, though it's better used alongside actually fixing the underlying URLs rather than as the sole fix.

Still Not Working?

If mixed content warnings persist despite fixing every URL you can find in your own code, check whether the issue originates from a redirect chain rather than a directly referenced URL — a resource requested over HTTPS that itself redirects to an HTTP URL server-side still triggers a mixed content warning, even though your original request was correctly secure. Testing the resource's actual URL directly (following any redirects manually) reveals this less obvious cause, which requires fixing the redirect configuration at the resource's own origin rather than anything in your page's code.

You might also like