Error explained3 min readUpdated 2026-08-03

Mixed Content error on HTTPS — what it means and fix

One insecure asset on a secure page — plus a warning about the directive that turns this into a blank site.


What it means

The page came over HTTPS but something on it — a script, stylesheet, image or API call — is requested over http://. Browsers block insecure scripts and stylesheets outright, because a network attacker could replace them and take over the page.

Why it happens in AI-built apps

  • A hardcoded http:// URL for an image, font or CDN script.
  • An API base URL configured as http:// in an environment variable.
  • A third-party embed that has not moved to HTTPS.
  • A redirect chain that drops to HTTP in the middle before coming back.

Is this error actually a problem?

Check it yourself

Find every insecure asset

  1. 1Open your live site, press F12, and read the Console — each blocked resource is listed by URL.
  2. 2Switch to the Network tab and sort by Protocol or Scheme to spot http:// entries.
  3. 3Search your source for the literal string http:// — most hits are the cause.
  4. 4Check environment variables for an API base URL still on http://.

Fix it

Copy this into your AI coding tool
My site reports Mixed Content errors.

1. List every resource being requested over http:// from my HTTPS pages —
   scripts, styles, images, fonts, iframes and API calls.
2. For each, change it to https:// if the host supports it, or replace the
   dependency if it does not.
3. Check environment variables and config files for http:// base URLs.
4. Check for redirect chains that pass through HTTP.
5. Make sure my own site redirects HTTP to HTTPS with a 301 and sends
   Strict-Transport-Security.

Do NOT add upgrade-insecure-requests to the Content-Security-Policy. Fix
the underlying URLs and tell me which ones they were.

Common questions

Why does the browser block only some resources?
Scripts and stylesheets are blocked outright, because a network attacker could replace them and take over the page. Images and other passive content are usually shown with a warning instead.
Can I fix it with upgrade-insecure-requests?
Avoid it. That CSP directive rewrites http:// to https:// automatically, which looks like a one-line fix — but on any origin still reachable over plain HTTP it also rewrites your own asset URLs, and if nothing is listening on TLS there the page loads with no CSS and no JavaScript. It behaves correctly on localhost, so it survives local testing and breaks in production.
How do I find what is loading over HTTP?
Open the live site, press F12 and read the Console — every blocked resource is listed by URL. Then search your source for the literal string http:// and check environment variables for an API base URL still on http://.

This is one check out of 40+

Paste your site address and we run the whole list from the outside — leaked keys, open databases, unprotected pages — then hand you one prompt that fixes what we find. Free, about 30 seconds, no signup.

Check my site — free