Mixed content checker
Find HTTP resources loaded on your HTTPS page — the silent killer of the secure padlock and SEO signals.
Paste an HTTPS URL above. We'll fetch the page and find every HTTP resource that breaks the secure padlock.
What mixed content actually is
When an HTTPS page loads any sub-resource (image, script, stylesheet, iframe) over plain HTTP, that's mixed content. Modern browsers refuse to load the most dangerous types (scripts, stylesheets, iframes) entirely, and quietly upgrade the rest (images, video) to HTTPS where possible — falling back to broken content when the upgrade fails.
The visible symptom is the green padlock disappearing, replaced by a “Not fully secure” warning. The invisible symptoms are broken images, unstyled chrome from a blocked CSS file, and missing analytics from a blocked script — none of which the user can debug.
Three severity levels
- Blocked — scripts, stylesheets, iframes, and other “active” content. Browsers refuse to load these on HTTPS pages. Functionality breaks. Fix immediately.
- Auto-upgraded — images, video, audio, and other “passive” content. Browsers try to upgrade these to HTTPS automatically. If the HTTPS version exists, the user sees nothing wrong; if not, the resource silently fails. The padlock still suffers in either case. Fix soon.
- Passive — form actions and similar attributes. Browsers warn the user when they try to submit. Fix to maintain trust.
How to actually fix mixed content
- Find every offending URL using the scan above.
- Try changing each URL from
http://tohttps://— the destination usually supports HTTPS already. - For your own assets, always link with protocol-relative paths (
/pathor//cdn.yourdomain.com/path) so the protocol matches the page. - For third-party resources that don't support HTTPS, you have two options: switch providers, or self-host a copy of the asset on your domain.
- Add a Content Security Policy header to your origin to enforce HTTPS-only loading from now on:
Content-Security-Policy: upgrade-insecure-requeststells modern browsers to upgrade everything automatically.
FAQ
Why don't I see mixed content errors on my site in Chrome?
Chrome (and most modern browsers) auto-upgrades passive mixed content silently. The HTTP image becomes HTTPS, you don't see a broken icon. But: the upgrade can fail, the padlock can downgrade, and SEO crawlers see the original HTTP URL in your HTML. The only reliable way to find mixed content is to scan the source — which is what this tool does.
Does mixed content hurt SEO?
Indirectly. Google's HTTPS ranking signal slightly penalizes pages with mixed content. Worse, if the mixed content includes critical CSS or JS, the page can render incorrectly during Google's crawl, which inflates rendering errors and hurts page-quality scores.
What does 'upgrade-insecure-requests' do?
It's a Content Security Policy directive. When set as an HTTP response header, it tells the browser to automatically upgrade every HTTP sub-resource on the page to HTTPS. Catches mixed content you missed and prevents future regressions. Add it to your origin server config — Nginx, Apache, Cloudflare, or your CDN.
I'm migrating from HTTP to HTTPS — what's the order of operations?
1. Get HTTPS working on the server. 2. Switch your absolute internal URLs to HTTPS or relative paths. 3. Run this scan to find remaining HTTP references. 4. Fix each one. 5. Add upgrade-insecure-requests as a safety net. 6. Set up a 301 redirect from HTTP to HTTPS at the server level.
Will my URL be saved?
No. We don't log inputs. Each scan is processed and discarded.
Why does the tool require an HTTPS URL?
Mixed content only matters on HTTPS pages — that's the whole concept. An HTTP page loading HTTP resources is just an HTTP page; nothing's mixed. We require HTTPS as input so we don't waste your time scanning a page that has no mixed-content concern.
Get the full Web Design Service workspace.
Want this monitored daily across all your projects? Sign up free.