Mixed Content Warning: Your HTTPS Site Is Loading HTTP Resources

You set up HTTPS on your site. The padlock shows up. But now some images are broken, a script isn't loading, or your API calls are failing. The browser console shows:

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

Your HTTPS page is trying to load something over HTTP. Browsers block this because it defeats the purpose of HTTPS — if any resource is unencrypted, the whole page is compromised.

What "mixed content" means

When your page loads over HTTPS (secure), every resource it loads — images, scripts, stylesheets, fonts, API calls, iframes — should also be HTTPS. If any resource uses plain HTTP, that's "mixed content."

Browsers handle two types differently:

• Mixed active content (scripts, stylesheets, iframes, fetch/XHR requests) — blocked entirely. These can modify the page, so the browser won't load them at all.
• Mixed passive content (images, video, audio) — loaded with a warning in most browsers, though some newer versions block these too.

How to find all mixed content

Open your browser's developer tools (F12) and look at the Console tab. Every mixed content issue shows a warning or error with the exact URL that's causing the problem.

Common sources:

• Hardcoded HTTP URLs in your code. Search your codebase for http:// and change them to https:// (or // for protocol-relative URLs).
• API endpoints. Your frontend calls http://api.yoursite.com instead of https://.
• Image URLs from a database or CMS. Old content was saved with http:// URLs before you added SSL.
• Third-party resources. External scripts, fonts, or images loaded over HTTP.
• Inline styles or HTML. Background images or other resources referenced with http:// in your HTML or CSS.

How to fix it

Fix 1: Change HTTP URLs to HTTPS. The simplest fix. If the resource supports HTTPS (most do), just change the protocol.

<!-- Before -->
<img src="http://example.com/image.jpg">
<script src="http://cdn.example.com/lib.js"></script>

<!-- After -->
<img src="https://example.com/image.jpg">
<script src="https://cdn.example.com/lib.js"></script>

Fix 2: Use protocol-relative URLs. Start with // instead of http:// or https://. The browser will use whatever protocol the page uses.

<img src="//example.com/image.jpg">

Note: this approach is falling out of favor since everything should be HTTPS now. Just use https://.

Fix 3: Use relative URLs for your own resources. Instead of hardcoding the full URL, use a path relative to your domain.

<!-- Instead of this: -->
<img src="http://yoursite.com/images/logo.png">

<!-- Do this: -->
<img src="/images/logo.png">

Fix 4: Fix API base URLs. If your frontend talks to your own API, make sure the base URL uses HTTPS.

// Wrong:
const API_URL = 'http://api.yoursite.com';

// Right:
const API_URL = 'https://api.yoursite.com';

// Best (use environment variable):
const API_URL = process.env.NEXT_PUBLIC_API_URL;

Fix 5: Update database content. If old content has hardcoded HTTP URLs, you need to update them in the database.

-- Update all HTTP image URLs to HTTPS in your posts table
UPDATE posts
SET content = REPLACE(content, 'http://yoursite.com', 'https://yoursite.com')
WHERE content LIKE '%http://yoursite.com%';

Fix 6: Add an upgrade-insecure-requests header. This tells the browser to automatically upgrade HTTP requests to HTTPS. It's a good safety net but not a substitute for fixing the actual URLs.

<!-- In your HTML head: -->
<meta http-equiv="Content-Security-Policy"
      content="upgrade-insecure-requests">

# Or as an HTTP header (nginx):
add_header Content-Security-Policy "upgrade-insecure-requests";

Force HTTPS redirect

While you're fixing mixed content, make sure your server redirects all HTTP traffic to HTTPS. This prevents users from landing on the HTTP version of your site.

# Nginx — redirect HTTP to HTTPS
server {
    listen 80;
    server_name yoursite.com;
    return 301 https://$server_name$request_uri;
}

Why this happens with AI-built apps

AI-generated code often hardcodes URLs or uses HTTP in examples because that's what appears most in training data (especially older documentation). When you add SSL later, all those hardcoded HTTP URLs become mixed content violations. A developer would use environment variables or relative URLs from the start, avoiding this entire category of bug.