Fix Mixed Content on HTTPS Pages

Mixed content occurs when an HTTPS page loads any resource (image, script, stylesheet, iframe) over HTTP. Modern browsers block or degrade these requests, which can break images, scripts, functionality, and layouts. Use this practical guide to find and remove mixed content quickly.

What mixed content looks like

• http:// references in HTML templates, CSS, or JavaScript
• Old CDN or library URLs still using http
• Third‑party embeds and iframes pointing to http
• Images or media inserted as http in a CMS

Why this should be avoided

• Security - an http subresource can be modified in transit
• Reliability - browsers increasingly block active mixed content
• SEO - broken resources hurt crawlability and Core Web Vitals

Quick analysis

1. Open DevTools, open Console and Network tabs, then reload the page
2. Filter or search for “Mixed Content” and expand blocked requests
3. Note the exact offending URLs and where they are referenced

Do a systematic cleanup

• Search the codebase for http:// and replace with https:// where supported
• Update config files and environment variables that contain hostnames
• Migrate third‑party scripts to documented https:// endpoints or official packages
• Update CMS content and media URLs to https://

Hidden offenders to check

• Grep CSS for url(http:// and fonts loaded over http
• Scan sitemaps and top pages with a headless fetcher to capture console warnings
• Check tag managers, A/B testing, and analytics snippets for legacy URLs
• Avoid protocol‑relative URLs like //example.com/... - instead explicitly use https://

Mitigation strategies that can help

These options reduce mixed content during cleanup, but they don’t solve every case. Use them as a bridge while you fix sources, and as a future failsafe. When the website is using proper HTTPS sources, keep your mitigation strategies, but stop relying on automatic upgrades. Instead, ensure that all assets are properly requested over the correct https:// URLs, instead of http://.

Content Security Policy

Content-Security-Policy: upgrade-insecure-requests

This tells the browser to try https:// for subresources that are accessed with http://. It helps during cleanup but will not fix sources that do not support HTTPS. For more information on how Content-Security-Policy (CSP) works, read our Content Security Policy guide.

CDN and edge rewrites

CDNs can upgrade insecure subresource URLs at the edge without a code change. Use this to reduce breakage during a transition, but scope rules to known hosts and verify that those origins actually serve HTTPS.

• Cloudflare: enable Automatic HTTPS Rewrites, optionally add Transform Rules to upgrade specific origins and block http‑only ones
• AWS CloudFront: use Functions or Lambda@Edge to rewrite http:// → https:// for a whitelist of origins, log rewrites and skip when an origin lacks HTTPS
• Fastly: use VCL or Compute@Edge to normalize schemes to https for known domains
• Akamai: use Property Manager/EdgeWorkers to enforce https on allowed hostnames
• Azure Front Door: add routing rules to enforce HTTPS and, when proxied, rewrite subresource URLs for known backends

Avoid blanket rewrites for unknown domains. Keep the scope narrow and auditable.

Server redirects

Force HTTPS with 301 redirects for HTTP requests at your web server and app layer. This fixes same‑origin mixed content where pages reference http://your-domain/.... It does not fix third‑party assets that don’t support HTTPS though.

Update canonical URLs, sitemaps, OG tags, and CMS templates to absolute https:// links. Verify cookies (use Secure) and CORS/asset URLs all work over HTTPS. When the site is fully migrated, consider enabling HSTS to prevent downgrades. See the HTTPS implementation guide for Nginx, Apache, IIS, Next.js, and CDN examples.

Adding an automated mixed content check to CI

Playwright (browser automation testing tool) example - fail the build on mixed content warnings

// scripts/mixed-content-check.ts
import { chromium } from 'playwright'

const urls = [
  'https://your-site.example/',
  'https://your-site.example/pricing',
  'https://your-site.example/blog'
]

let hadMixed = false

;(async () => {
  const browser = await chromium.launch()
  const ctx = await browser.newContext()
  const page = await ctx.newPage()
  page.on('console', (msg) => {
    if (msg.type() === 'warning' && /Mixed Content/i.test(msg.text())) {
      hadMixed = true
      console.warn(msg.text())
    }
  })
  for (const url of urls) {
    await page.goto(url, { waitUntil: 'networkidle' })
  }
  await browser.close()
  if (hadMixed) {
    console.error('Mixed content detected')
    process.exit(1)
  }
})()

Or run a quick search in CI to catch new http:// strings:

rg -n "http://" src/ content/ public/

Common pitfalls

• Protocol‑relative URLs (//) pulling HTTP from legacy hosts
• CSS files hiding HTTP font/image URLs
• Hardcoded links in marketing tools or CMS blocks

Release checklist

• DevTools shows no mixed content warnings on key pages
• Sitemap, canonical, and OG image links are https
• All third‑party embeds use documented https:// endpoints
• Images, fonts, CSS, and JS load over https in the Network tab
• Some automated mitigation attempt strategy in place, such as the upgrade-insecure-requests CSP directive

Conclusion

Replace HTTP links with HTTPS in the source - code, configuration, and content. Use CSP auto upgrade and CDN rewrites as temporary aids, not permanent fixes. Keep it clean with automated checks.

Next steps

• Verify headers quickly with the Security Headers Test
• Scan your public pages for issues in the Barrion dashboard