Mixed Content Checker Guide
Use this guide to understand what the Mixed Content Checker is validating, which insecure asset patterns are highest priority, and how to clean up HTTPS pages without leaving browser warnings or blocked resources behind.
Overview
Mixed content weakens the trust boundary of an HTTPS page by pulling scripts, styles, images, or API calls over insecure origins. The checker is trying to highlight where the page still depends on plaintext resources or redirect patterns that leave browsers warning, blocking, or quietly degrading the experience.
Mixed-content problems to prioritize first
- Active content: Scripts, stylesheets, iframes, and XHR calls are the most urgent because browsers often block them outright.
- Hard-coded HTTP URLs: Templates, CMS fields, and older content often contain URLs that escaped an HTTPS migration.
- Third-party asset dependencies: Some external providers still do not serve a clean HTTPS endpoint or redirect poorly.
Asset Classes and Risk
| Asset type | Typical browser behavior | Expected fix |
|---|---|---|
| JavaScript or XHR | Often blocked as active mixed content | Move the asset or endpoint to HTTPS immediately. |
| Stylesheets or fonts | May be blocked or fail silently depending on the browser | Update source URLs and confirm the provider supports HTTPS cleanly. |
| Images or media | Sometimes allowed with warnings, but still weakens the page | Upgrade the source or host the asset yourself. |
| Form or API target | Can leak data or break user actions | Move the destination to HTTPS and update app configuration. |
Practical Cleanup Examples
<script src="https://cdn.example.com/app.js"></script>
<link rel="stylesheet" href="https://cdn.example.com/app.css">
<img src="https://images.example.com/logo.png" alt="Brand logo">Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-contentRecommended Remediation Flow
- Classify blocked and warned resources Separate active content from passive assets so the highest-impact fixes land first.
- Replace hard-coded HTTP origins Update templates, CMS content, and configuration values that still reference plaintext URLs.
- Review third-party dependencies Confirm each external provider supports the HTTPS endpoint you are about to depend on.
- Retest real pages over HTTPS Validate key templates and user journeys after the cleanup, not just one example page.
Troubleshooting Common Issues
The page still warns even after updating obvious URLs
Background images, CSS imports, old CMS fields, or runtime-generated URLs are often missed during the first pass.
- Inspect browser DevTools for the exact blocked or warned resource.
- Search templates and stored content for hard-coded http:// values.
- Check whether a script rewrites asset URLs dynamically after load.
A third-party provider does not support HTTPS cleanly
You may need to replace the provider, self-host the asset, or remove the dependency.
- Test the exact third-party endpoint over HTTPS before relying on it.
- Avoid leaving the browser to auto-upgrade a provider that still redirects poorly.
- Treat business-critical assets differently from low-value decorative ones.
Validation Checklist
Post-fix validation
- Confirm key pages load without mixed-content warnings in the browser.
- Review active content such as scripts, stylesheets, and API calls first.
- Verify third-party providers and CDN assets resolve cleanly over HTTPS.
- Run the Mixed Content Checker again and compare the remaining findings against the cleaned asset inventory.
FAQ
Is an image warning less serious than a script warning?
Usually yes, but it still weakens HTTPS trust and should still be cleaned up.
- Prioritize active content first.
- Do not leave image warnings behind permanently just because the page still renders.
- Clean the full asset set once the urgent fixes land.
Can CSP upgrade-insecure-requests replace real cleanup?
It can help temporarily, but it is not a substitute for fixing the underlying URLs and dependencies.
- Use it as a safety net, not the only remediation.
- Confirm third-party providers support HTTPS cleanly.
- Retest after the real source URLs have been corrected.