Why mixed content still matters

Serving your site over HTTPS is only half the battle. If any subresource—an image, script, stylesheet, or iframe—is loaded over plain HTTP, you've introduced mixed content. Browsers are increasingly aggressive about blocking these insecure requests, so knowing how to find and fix them is essential.

Spotting mixed content in the browser

In Chrome, open DevTools on any HTTPS page. Console messages will flag two kinds of mixed content:

  • Passive mixed content (images, video, audio): The browser may automatically upgrade the request to HTTPS if the resource is available securely, and will log a message when it does.
  • Active mixed content (scripts, iframes, stylesheets): These requests are blocked outright, and you'll see a corresponding error.

When you see these warnings for http:// URLs on your own site, make a note of the URL and the page where it appears. You'll need that list when you fix the source.

Searching your source code

A simple text search for http:// in your codebase is the first step. Look for tags that carry URL attributes: <img src>, <script src>, <link href>, and so on. Anchor tags (<a href>) are usually fine—they trigger a full page navigation, not a subresource fetch. The notable exception is when JavaScript overrides that default behavior, such as gallery scripts that load the linked resource into a lightbox.

If you use a CMS, images and other assets may be stored with absolute http:// URLs in the content itself. Those need to be corrected wherever they appear in published pages.

Fixing insecure URLs

For each flagged http:// resource:

  1. Try changing the URL to https:// directly in your code. If the resource resolves over HTTPS, you're done.
  2. If the resource isn't available over HTTPS, consider: serving it from a different host, hosting a copy on your own domain (provided you have the rights), or removing it entirely.

After making changes, reload the original page and confirm the console warning is gone.

Scaling up with Content Security Policy

Manual checking works for small sites. For larger properties or teams, rely on Content Security Policy (CSP) to monitor and enforce secure resource loading.

Collecting reports

Set the Content-Security-Policy-Report-Only header to gather violation reports without blocking anything:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportingEndpoint

The browser will POST JSON reports to the specified endpoint whenever a page loads a subresource over HTTP. Each report includes the page URL and the offending subresource URL. Log those reports to track mixed content without manually visiting every page.

Two caveats: users must visit pages in a browser that understands CSP (true for all modern browsers), and you only get data for pages that receive traffic. Low-traffic pages may go unnoticed for a while.

If you can't modify response headers—for instance, on a hosted platform like Blogger—use a crawler such as HTTPSChecker or the open-source Mixed Content Scan tool instead.

Enforcing upgrades with CSP

Beyond reporting, you can actively force secure requests. The upgrade-insecure-requests CSP directive tells the browser to rewrite http:// URLs to https:// before issuing network requests. For example, an image tag referencing http://example.com/image.jpg will be fetched from https://example.com/image.jpg instead.

Send the directive as a response header:

Content-Security-Policy: upgrade-insecure-requests

Or embed it inline in the document's <head>:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

If the resource isn't available over HTTPS, the upgraded request fails and the resource is not loaded. This directive goes beyond what browsers automatically upgrade, and it cascades into <iframe> documents, protecting the entire page.