Mixed Content: How to Find and Fix HTTP Resources on HTTPS

You moved your site to HTTPS, the certificate is valid, and you still get a warning in the address bar or a partly broken page. That is almost always mixed content: the page loads securely, but a resource inside it is still requested over http://. Here is what the check flags and how to clear it.

What this check flags

The check fires when a page served over https:// loads one or more sub-resources over insecure http://. Those resources can be almost anything the page embeds: images, scripts, stylesheets, fonts, videos, audio, iframes, or fetch calls. The browser fetched the HTML securely, but the moment it hits an http:// reference inside it, that piece is no longer encrypted. An attacker on the same network can read or tamper with anything on that open channel, which defeats the point of the certificate.

This differs from a page that simply answers on both protocols. If your concern is that the same URL responds on http and https without a redirect, read HTTP and HTTPS both resolve. Mixed content is about what a secure page pulls in.

Active vs passive mixed content

Browsers split mixed content into two buckets by how much damage a tampered resource could do.

Active mixed content is anything that can change the rest of the page: scripts, stylesheets, iframes, and fetch requests. A script loaded over http:// can be swapped in transit and run code on your page, read cookies, or rewrite the document. The risk is high.

Passive mixed content only displays and cannot reach into the page: images, video, and audio. A tampered image is still a problem, but it cannot hijack your page the way a script can, so browsers treat it more leniently.

What browsers actually do

Modern browsers block active mixed content by default. The http:// script or stylesheet never loads, which is why a page "looks broken" after an HTTPS migration: the layout collapses because the CSS was blocked, or a feature dies because its JavaScript never ran. Visitors have no toggle to fix this.

Passive mixed content is handled more gently. Browsers now try to upgrade the request to HTTPS automatically, and if that fails the resource may load while the page loses its padlock. Do not rely on auto-upgrade; it only works when the resource exists at the HTTPS address.

Why it matters

Three reasons, in order. Security: any http:// resource is an open door for someone to read or alter what loads on your page. Trust: the broken padlock and "not secure" wording cost you credibility at the moment a visitor decides whether to fill in a form or check out. Function: blocked active content means broken pages, and a broken page does not convert, get crawled cleanly, or hold a ranking. HTTPS is a baseline expectation now.

How to fix it

Start at the source. Every embedded resource should point to https:// or to a relative path that inherits the page protocol. Track down where the http:// references live:

Database content. On a CMS like WordPress, old http:// links hide inside post content, options, and widget settings. Run a search-and-replace across the database rather than editing posts by hand:

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://yoursite.com', 'https://yoursite.com');

Back up first, and use a tool that handles serialized data correctly so you do not corrupt theme settings.

Templates and theme files. Hardcoded http:// URLs hide in headers, footers, and partials. Grep your theme and convert each one. Where you control the markup, relative references are the cleanest fix:

<img src="//cdn.example.com/logo.png" alt="Logo">
<link rel="stylesheet" href="/assets/style.css">

Add a safety net. Once the obvious references are clean, set an upgrade-insecure-requests policy so the browser rewrites any stray http:// request to https:// before it goes out:

Content-Security-Policy: upgrade-insecure-requests

This catches references you missed, including ones injected by third-party code. It is a backstop, not a substitute for fixing the real URLs, because it only works when the resource is available over HTTPS. Do not pair it with the obsolete block-all-mixed-content directive; the upgrade directive already covers it.

How to diagnose it

Open the page and look at the browser console. It lists every blocked or insecure resource with its exact URL, and the Network tab shows the same requests with their protocol. For a whole-site view, run a crawl that flags HTTP resources on HTTPS URLs, catching references buried on pages you would never check by hand.

Common mistakes

The biggest one is assuming an HTTP-to-HTTPS redirect fixes mixed content. It does not. An active resource is often blocked before any redirect can run, so the redirect never gets a chance. The fix is to change the reference, not to rely on a redirect catching it.

Other frequent slips: editing visible post content but forgetting the database options table, fixing your own templates while leaving a third-party widget or ad tag on http://, and hardcoding the full https://yoursite.com prefix so the problem returns the next time you change domains. Reach for relative paths where you can.