How do I fix mixed content errors on an HTTPS site?

A page that loads over HTTPS can still pull some of its assets over plain HTTP, and browsers do not let that slide. That condition is called mixed content: a securely loaded page that requests a resource over an insecure connection. Browsers either silently upgrade or hard-block those requests depending on the resource type, so the problem often surfaces as one broken script or a missing stylesheet rather than a loud warning. Here is how to fix mixed content properly and confirm the fix actually held.

Why this matters

An HTTPS connection encrypts the traffic for the page and its subresources, so nobody on the network can read or alter them in transit. The moment a single resource is fetched over HTTP, an attacker on the same network can intercept or replace it, and the browser can no longer claim the page is fully secure. Browsers split the problem into two groups. Upgradable content, such as images, audio and video referenced through a src attribute, is automatically rewritten from http to https. Blockable content, such as scripts, stylesheets, iframes, fetch() calls, XMLHttpRequests, web fonts and CSS url() values, is refused outright. The consequences range from a stripped-down layout to a third-party script an attacker controls, and any injected script runs with full access to the page, its cookies and anything the user types. Because the failure is usually silent, mixed content tends to linger until a browser update tightens its policy and something finally breaks, which is why the automated mixed content finding is worth clearing early rather than treating it as cosmetic noise.

How to fix it

The durable fix is to serve and reference every resource over HTTPS. Replace http:// URLs with https://, or point assets on your own domain at relative links, then confirm that each third-party host offers an HTTPS endpoint. When you have a large backlog of hard-coded insecure URLs, the CSP upgrade-insecure-requests directive rewrites insecure requests for you, including the blockable types the browser would otherwise refuse.

<!-- Insecure: upgraded or blocked by the browser -->
<script src="http://cdn.example.com/widget.js"></script>
<img src="http://cdn.example.com/photo.png">

<!-- Secure -->
<script src="https://cdn.example.com/widget.js"></script>
<img src="https://cdn.example.com/photo.png">

<!-- Rewrite insecure requests at the policy layer -->
Content-Security-Policy: upgrade-insecure-requests

How to verify the fix

Load the page in a browser, open DevTools and keep the Console visible while the page renders; mixed content is reported there, and the Security panel will not show a fully secure connection while any insecure request remains. To catch references without executing the page, fetch the HTML and search it for http:// URLs. Keep in mind that upgrade-insecure-requests only rewrites non-navigational requests, so it does not upgrade top-level navigations that arrive from third-party links, and it does not replace HSTS.

curl -s https://example.com | findstr "http://"

Related issues