TL;DR: Mixed content occurs when a page served securely over HTTPS loads some resources — images, scripts, stylesheets, fonts, iframes — over insecure HTTP. Browsers block “active” mixed content (scripts, iframes, stylesheets) outright because it can hijack the whole page, and they’re increasingly upgrading or blocking “passive” mixed content (images, media) too. The result is broken layouts, missing functionality, and security warnings that erode public trust in a government site. Find it with your browser’s DevTools console, a Content-Security-Policy report-only header, or an automated crawler, then fix it by serving every resource over HTTPS.

A government website that loads over https:// is supposed to signal safety: the padlock in the address bar tells constituents their connection is encrypted and the site is authentic. Mixed content quietly undermines that promise. When a secure page pulls in even one resource over plain http://, the browser has to decide whether to block it, downgrade the page’s security indicators, or load it anyway — and none of those outcomes are good for a public agency. This guide explains what mixed content is, why modern browsers treat it so aggressively, and exactly how to find and fix it on your site.

For government teams, mixed content is more than a cosmetic bug. A broken permit form, a missing map, or a “Not Secure” warning on a tax-payment page directly affects residents trying to access services — and it signals to anyone evaluating the site that security hygiene has slipped.

What Mixed Content Is

Every government website should be served entirely over HTTPS — the encrypted, authenticated version of HTTP. CISA’s directives made HTTPS mandatory for federal sites, and it’s the universal baseline for state and local government now too (we cover the broader picture in our guide to CISA cybersecurity recommendations for government websites).

Mixed content happens when the main HTML document is delivered over HTTPS, but that page then references one or more sub-resources using insecure http:// URLs. The page is “mixed” because it combines secure and insecure connections.

A page is made up of many resources beyond the HTML itself:

  • Images, video, and audio
  • Stylesheets (CSS)
  • Scripts (JavaScript)
  • Fonts
  • Iframes (embedded pages like maps, videos, or forms)
  • Background requests (XMLHttpRequest / fetch, web socket connections)

If the HTML is loaded over HTTPS but any of those sub-resources is requested over HTTP, you have mixed content. The insecure request travels unencrypted, which means anyone positioned on the network path — on public Wi-Fi, a compromised router, or a hostile ISP — can read or tamper with it.

A common way this happens on government sites: a content editor pastes an image embed copied from an old page, and the URL hard-codes http://www.city.gov/images/seal.png instead of https://... or a protocol-relative path. The page itself is secure; that one image request isn’t.

Active vs. Passive Mixed Content

Browsers don’t treat all mixed content the same way, because not all resources carry the same risk. The distinction is active versus passive.

Active mixed content (high risk — blocked)

Active mixed content is any resource that can change or control the rest of the page. The big three are:

  • Scripts (<script src="http://...">)
  • Stylesheets (<link rel="stylesheet" href="http://...">)
  • Iframes (<iframe src="http://...">)

Also in this category: web fonts, XMLHttpRequest/fetch calls, and several others. The risk is severe: if an attacker can intercept and modify an insecurely loaded script, they don’t just alter one element — they gain control of the entire page. They could rewrite a payment form to send card details to themselves, inject fake content, or steal session cookies.

Because the danger is so high, modern browsers block active mixed content outright. The resource simply doesn’t load. On a government site this typically manifests as: a payment widget that never appears, a search box that doesn’t work, an interactive map that’s blank, or a page whose entire layout collapses because its stylesheet was blocked.

Passive mixed content (lower risk — upgraded or blocked)

Passive (or “display”) mixed content is resources that are shown but can’t alter the rest of the page:

  • Images (<img src="http://...">)
  • Audio and video (<audio>, <video>)

The risk is lower — the worst case is an attacker swaps an image — so historically browsers loaded passive mixed content but stripped the padlock and showed a “Not Secure” or “Not fully secure” indicator. That’s changing fast. Chrome, Firefox, Edge, and Safari now automatically upgrade passive mixed-content requests to HTTPS where possible, and if the resource isn’t available over HTTPS, they block it rather than load it insecurely. So in 2026 the practical assumption should be: all mixed content, active or passive, will eventually fail to load.

Why Browsers Block Mixed Content

It comes down to a simple principle: a secure page is only as secure as its weakest request. Encrypting the HTML but loading a script in the clear is like putting a steel door on a house with an open window. An attacker conducting a man-in-the-middle attack ignores the encrypted parts and targets the insecure request — and through an active resource, that single insecure request compromises the whole page.

Browser vendors decided years ago that giving users a false sense of security (a padlock on a page that’s actually partly insecure) is worse than breaking the page. So they err toward blocking. For government sites this means a mixed-content problem isn’t something you can ignore and hope users tolerate — the browser actively removes the broken functionality and, in many cases, shows the visitor a warning.

How Mixed Content Breaks Government Pages and Erodes Trust

The consequences fall into three buckets:

  1. Broken functionality. Blocked active content takes real services down. Examples from the public sector: an online utility-payment iframe loaded over HTTP that no longer renders, so residents can’t pay their water bill; a Granicus or CivicPlus widget embedded with an http:// URL that disappears; a county GIS map iframe that goes blank; a third-party translation script that’s blocked, leaving non-English-speaking residents without the language tools they were promised.

  2. Visible security warnings. A “Not Secure” label, or a padlock with a warning triangle, on a page where a constituent is entering personal information, paying a fee, or filing a complaint. Even when nothing is technically stolen, the warning tells the visitor the government can’t be trusted to run its own website securely.

  3. Compliance and procurement red flags. Mixed content shows up immediately in any security scan, and it signals that a site’s HTTPS migration was never finished. It undermines the security posture you’ve built with proper security headers and is a routine line item on a government website compliance checklist.

How to Find Mixed Content on Your Site

1. Browser DevTools console (fastest manual check)

This is the quickest way to check any single page:

  1. Open the page in Chrome, Edge, or Firefox.
  2. Press F12 (or right-click → Inspect) to open Developer Tools.
  3. Click the Console tab and reload the page.
  4. Look for messages like:
    • Mixed Content: The page at 'https://www.city.gov/pay' was loaded over HTTPS, but requested an insecure script 'http://...'. This request has been blocked.
    • Mixed Content: ...was loaded over HTTPS, but requested an insecure image '...'. This content should also be served over HTTPS.

The console names the exact insecure URL and tells you whether it was blocked or merely flagged. The Security panel in Chrome DevTools (under “More tools”) also summarizes a page’s mixed-content status and lists insecure origins.

The limitation: this checks one page at a time. A government site can have thousands of pages, and the worst offenders are often deep in legacy content no one looks at.

2. Content-Security-Policy in report-only mode (site-wide discovery)

A Content-Security-Policy (CSP) is an HTTP response header. You can use it to discover mixed content across real traffic without breaking anything, by deploying it in report-only mode. The browser checks every request against the policy and sends a report when it finds a violation, but doesn’t enforce blocking.

Add a header like this:

Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri /csp-violation-report

Or, more targeted, use the directive built specifically for this problem:

Content-Security-Policy-Report-Only: upgrade-insecure-requests; report-uri /csp-violation-report

Your server logs the reports at the report-uri endpoint, giving you a real-world inventory of every insecure resource your visitors actually encountered — across every page, including ones you’d never think to test manually.

Once you’ve found and fixed everything, switch to the enforcing version of the policy and add the upgrade-insecure-requests directive, which tells browsers to automatically rewrite any remaining http:// sub-resource requests to https://:

Content-Security-Policy: upgrade-insecure-requests

This is a safety net, not a substitute for fixing the URLs — but it’s a powerful belt-and-suspenders measure for large legacy sites. CSP setup pairs naturally with the rest of your header configuration in our security headers guide.

3. Automated crawlers and scanners

For a full site, you need to crawl every page:

  • Online testers like the “Why No Padlock?” tool or SSL Labs–style scanners check individual pages for mixed content.
  • Site crawlers (Screaming Frog, Sitebulb) can be configured to flag insecure resource requests across an entire crawl.
  • Continuous monitoring crawls the whole site on a schedule and flags new mixed-content issues as they’re introduced — which matters because the most common cause is a content editor pasting an http:// URL into a new page next week.

How to Fix Mixed Content

Fixing is conceptually simple — make every resource load over HTTPS — but the right method depends on the source.

Fix resources you control

If the insecure resource lives on your own domain and is already available over HTTPS (it almost always is, once your HTTPS migration is done), just change the URL from http:// to https://, or use a protocol-relative or relative URL:

<!-- Before -->
<img src="http://www.city.gov/images/seal.png">
<script src="http://www.city.gov/js/main.js"></script>

<!-- After -->
<img src="https://www.city.gov/images/seal.png">
<script src="/js/main.js"></script>

For hard-coded URLs scattered across a database (the usual situation in WordPress and Drupal), a bulk find-and-replace is the efficient fix.

WordPress

  • Use a search-and-replace plugin (such as Better Search Replace) or the WP-CLI command wp search-replace 'http://www.city.gov' 'https://www.city.gov' to update hard-coded links in posts, pages, and widgets. Back up the database first.
  • Ensure the WordPress Address and Site Address under Settings → General both use https://.
  • Plugins like “SSL Insecure Content Fixer” can rewrite remaining insecure requests, but treat them as a stopgap while you fix the source.

Drupal

  • Update the base URL configuration and run a search-and-replace against the database (modules and Drush commands exist for this).
  • Drupal’s CSP module can deploy upgrade-insecure-requests and report-only policies cleanly.

Fix third-party resources

If the insecure resource is hosted by a third party — an embedded map, video, payment widget, analytics script, or font:

  1. Check whether the provider offers an HTTPS URL (almost all do in 2026). Update the embed code to the https:// version. This covers most cases: Google Maps, YouTube, Vimeo, modern payment and translation widgets, and font CDNs all serve over HTTPS.
  2. If a provider genuinely has no HTTPS option, that vendor is too far behind to embed on a secure government page — replace it. Do not weaken your site to accommodate an insecure third party.

Verify after fixing

Re-run the DevTools console check and your crawler. The console should be free of mixed-content messages, the padlock should be solid on every page, and any CSP report endpoint should go quiet.

Mixed content is the kind of problem that’s invisible until a browser update turns a “Not Secure” warning into a fully broken payment page — and on a government site, that broken page is a resident who can’t get a service. Because the most common cause is a single pasted http:// URL in newly published content, the issue creeps back even after a clean fix. That’s why one-time scans aren’t enough. Govzu continuously monitors government websites for mixed content alongside accessibility, privacy, and performance regressions — so when a contributor introduces an insecure resource, your team finds out from an alert, not from a constituent who couldn’t pay their bill. Pair it with a recurring compliance checklist and your site stays fully secure as content changes.

mixed content HTTPS security browser warnings government websites
All Resources
Share