Mixed Content: Load Everything over HTTPS
Mixed content happens when a page served over HTTPS loads some of its resources, such as scripts,
stylesheets, frames or images, over plain http://. The page itself is encrypted, but those
resources are not.
Why it matters
Anything fetched over HTTP can be read and changed by someone on the network path. For a script or stylesheet, that means an attacker can rewrite it and take control of the whole page, which undoes the protection HTTPS was meant to give. For an image or video, the risk is smaller but real: it can be swapped, and it reveals what the visitor is viewing.
Browsers respond in two ways:
- Active content (scripts, stylesheets, frames, plugin objects) is blocked outright. Whatever depended on it, such as layout, menus or checkout, breaks.
- Passive content (images, audio, video) is upgraded to HTTPS automatically by modern browsers. If the resource is not available over HTTPS, it fails to load.
Either way, the browser may stop showing the page as fully secure.
What we check
We look at the HTML of the scanned page for resource URLs that start with http://.
| Check | Passes when |
|---|---|
| No mixed content | no script, stylesheet, frame, object, image, audio or video uses an http:// URL |
- An
http://URL in<script src>,<link rel="stylesheet" href>,<iframe src>or<object data>fails the check (active content). - An
http://URL in<img src>,<audio src>,<video src>or<source src>is reported as “needs attention” (passive content). - On a page that is not served over HTTPS, the check is informational.
The report lists up to ten of the URLs we found. We read the HTML as your server sends it. We do
not run JavaScript, and we do not inspect srcset, CSS files or requests made by scripts, so a
clean result here is a good sign, not a full guarantee. Your browser’s developer console shows a
warning for every mixed-content request on a page, including those.
How to fix
- Find the insecure URLs. Start with the list in your report. Then open the page with the
developer tools console visible, and search your templates, theme files and stored content for
http://. - Switch each one to
https://. Nearly every CDN, font service, analytics and embed provider supports HTTPS. Check that the HTTPS URL actually loads before you change it. - Host it yourself if needed. If a third party does not offer HTTPS, download the file (if its license allows) and serve it from your own site, or replace the provider.
- Use relative or HTTPS links for your own assets. For resources on your own domain, a
root-relative path such as
/assets/app.jsavoids the problem entirely.
Content stored in a database
CMS posts and product descriptions often contain hard-coded http:// image URLs from before the
site moved to HTTPS. Update them in bulk with your CMS’s tools. For WordPress, WP-CLI can do it:
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run
Remove --dry-run once the preview looks right, and take a database backup first.
A safety net: upgrade-insecure-requests
The CSP directive upgrade-insecure-requests tells browsers to request every http:// resource on
the page over HTTPS instead:
Content-Security-Policy: upgrade-insecure-requests
Nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;
If you already send a Content Security Policy, add the directive to that header instead of sending a second one.
This is useful while you clean up, and for old content you cannot easily edit. It does not make a
resource available over HTTPS: if the host does not support HTTPS, the request still fails. It also
does not change your HTML, so this check keeps reporting the http:// URLs until you fix the source.
Treat it as a backup, not the fix.
Prevent it from coming back
- Make sure your site’s base URL setting (in your CMS or framework) uses
https://. - Have editors paste HTTPS embed codes, or let the editor rewrite URLs automatically.
- Re-scan after theme updates, new plugins or content migrations.
Further reading: MDN: Mixed content and web.dev: Fixing mixed content.