Mixed Content: The page was loaded over HTTPS, but requested an insecure resource

The exact error

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

// or, for images/media (a warning rather than a hard block, in
// most current browsers):
Mixed Content: The page at 'https://example.com/' was loaded over
HTTPS, but requested an insecure image 'http://example.com/logo.png'.
This content should also be served over HTTPS.

The wording difference between "has been blocked" and "should also be served over HTTPS" is meaningful, not incidental — it reflects a deliberate distinction browsers draw between resource types, covered in detail below.

How to read this error in 30 seconds

1. Open DevTools Console — every mixed-content resource on the page is listed individually, with its exact URL.
2. Check whether it says "has been blocked" (active content: script/stylesheet/iframe — nothing loaded at all) or "should also be served over HTTPS" (passive content: image/media — it loaded, but insecurely, with a browser warning).
3. Search your templates/source for the exact hostname/path named in the message.
4. If it's not in your own markup, check whether it's coming from stored database content or a third-party embed snippet.

Cause 1 — a hardcoded http:// URL in your own markup or CSS

<!-- ❌ absolute HTTP URL, left over from before the site moved to HTTPS: -->
<script src="http://cdn.example.com/widget.js"></script>

<!-- ✅ explicit HTTPS: -->
<script src="https://cdn.example.com/widget.js"></script>

<!-- ✅ or protocol-relative — inherits whatever protocol the page itself used: -->
<script src="//cdn.example.com/widget.js"></script>

This is the simplest and most common cause: a URL written as an absolute http:// reference somewhere in your HTML, inline <style> block, or an external CSS file's url(...) reference, most often left over from a period before the site adopted HTTPS everywhere, or copy-pasted from documentation/an example that predates the provider's own move to HTTPS. The fix is a direct search-and-replace to https://, or switching to a protocol-relative URL (//host/path, with no scheme at all) which automatically matches whatever protocol served the current page — a pattern that was especially popular during the industry-wide HTTP-to-HTTPS transition years ago specifically to avoid this exact class of bug.

Cause 2 — stored database/CMS content still has old absolute HTTP URLs

-- find every stored post/page body still referencing plain HTTP:
SELECT id, title FROM posts WHERE content LIKE '%http://%';

-- a one-time cleanup pass — swap the scheme in already-stored HTML
-- (adjust the domain/pattern to match your own migration):
UPDATE posts
SET content = REPLACE(content, 'http://example.com/', 'https://example.com/')
WHERE content LIKE '%http://example.com/%';

Content that lives inside a database — blog post bodies, page builder content, user-submitted HTML — is fundamentally different from your template code: migrating the site's own delivery to HTTPS changes nothing about strings already sitting in stored rows. Every historical post or page that embedded an absolute http:// image, iframe, or script URL keeps referencing that scheme indefinitely, since nothing about a protocol migration retroactively rewrites already-persisted content. This is why mixed-content errors often surface specifically on older content and not on anything published after the HTTPS migration — new content is written with the correct scheme from the start, while old content silently carries the bug forward until it's explicitly cleaned up.

Cause 3 — a third-party embed/widget snippet you don't control

<!-- an old copy-pasted widget snippet, hardcoded to HTTP by
     whoever wrote it, possibly years ago: -->
<script src="http://widgets.thirdparty.com/embed.js"></script>

<!-- check the provider's current docs for an HTTPS-compatible
     snippet before assuming none exists — most services updated
     theirs years ago and just never told existing integrators -->

Unlike Causes 1 and 2, this one isn't fixable by editing your own code at all — the mixed content originates from markup served by a third party's domain, entirely outside your control. The practical fix is checking whether the provider now offers (almost all mainstream ones do, at this point) an HTTPS version of the same embed snippet and swapping to it, or, if the integration is genuinely abandoned/unmaintained by its provider, removing it and finding an alternative rather than leaving a permanently broken, insecure dependency on the page.

Cause 4 — the resource genuinely isn't available over HTTPS at all

# confirm whether HTTPS is actually available at that host before
# assuming a simple scheme swap will work:
curl -I https://cdn.example.com/widget.js
# a connection failure or certificate error here means the resource
# truly has no HTTPS endpoint — the fix is finding a different host
# for that resource, not just changing http:// to https:// in place

Occasionally the underlying resource is hosted somewhere that has never had TLS configured at all — an old internal tool, an abandoned CDN bucket, a legacy asset server nobody migrated. In this case, simply rewriting the URL's scheme to https:// produces a new, different failure (a connection error or certificate mismatch) rather than fixing anything, because there's genuinely nothing listening for HTTPS at that host. The actual fix here is either self-hosting the resource on infrastructure that does support HTTPS, or finding an alternative HTTPS-capable source for the same asset.

The blanket fix: Content-Security-Policy upgrade-insecure-requests

<!-- add to your page's <head>, or set as a response header instead: -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

# or as an actual HTTP response header (nginx example):
add_header Content-Security-Policy "upgrade-insecure-requests";

This directive tells the browser to automatically rewrite every http:// subresource URL on the page to https:// before it's ever requested, rather than blocking or warning about it. It's a genuinely useful, low-effort mitigation specifically for Causes 2 and 3 above — cases where finding and manually fixing every individual instance (scattered across years of stored content or embedded in third-party markup) is impractical — but it only works when the same resource is actually reachable over HTTPS at the same hostname; if it isn't (Cause 4), the upgraded request simply fails outright rather than silently falling back to the insecure version, which is the correct, secure behavior even though it doesn't magically fix an HTTPS-incapable host.

Common variants

Debugging checklist

• ✓ Read every mixed-content line in the DevTools Console — each names the exact blocked URL
• ✓ Search your templates/CSS for the exact hostname/path named
• ✓ If not found in your markup, check stored database/CMS content for old absolute HTTP URLs
• ✓ If it's a third-party embed, check for an HTTPS-compatible version of that snippet
• ✓ Confirm the target host actually supports HTTPS (curl -I https://...) before assuming a scheme swap alone will work
• ✓ Consider Content-Security-Policy: upgrade-insecure-requests as a blanket mitigation for hard-to-reach instances