Scan an HTTPS page for insecure http:// resources — images, scripts, stylesheets and iframes — that trigger “not secure” browser warnings and block the padlock.
⚡ Interactive demo — sample data
Page is on HTTPS but loads 4 insecure http:// resources — including a script the browser will block.
Page served over HTTPSLooks good
<script> http://cdn.example.com/widget.js — active content, blocked by browsers (can break the page)Issue
<link> http://example.com/styles/main.css — insecure stylesheet, blocked by browsersIssue
<img> http://example.com/images/banner.jpg — insecure image, downgrades the padlockIssue
<iframe> http://maps.example.com/embed — insecure iframe, blocked by browsers (widget vanishes)Issue
4 insecure resources total — switch each http:// URL to https:// and re-runWarning
Scan an HTTPS page for insecure http:// resources — images, scripts, stylesheets and iframes — that trigger “not secure” browser warnings and block the padlock.
How it works
Enter your page URL
Paste an HTTPS page and run the check. We fetch the page, follow it to its final URL to confirm it actually ends on HTTPS, and then scan the HTML for resources that load over insecure http://.
See the insecure resources
You get a count of every resource loaded over http:// on the page and a list of the offenders — images, scripts, stylesheets, iframes, and media. These are the items that break the padlock and trigger browser warnings on an otherwise secure page.
Switch them to HTTPS and re-run
Update each flagged URL from http:// to https:// (or to a protocol-relative or relative path), confirm the resource is reachable over HTTPS, and re-run. A clean page shows zero insecure resources and a full secure padlock.
What we check
Final HTTPS status — Confirms the page itself ends up on HTTPS after any redirects. Mixed content only applies to secure pages — an insecure http:// resource on an HTTPS page is the problem. If the whole page is still on HTTP, that's the bigger issue to fix first.
Insecure images — Flags <img> tags with an http:// source. Insecure images are 'passive' mixed content — browsers usually still load them but downgrade the padlock and may warn. They're the most common offender, often left behind in old content or hardcoded URLs.
Insecure scripts — Flags <script> tags loaded over http://. Scripts are 'active' mixed content and the most dangerous kind — a script fetched insecurely can be tampered with in transit and run with full access to your page. Modern browsers block these outright, often breaking the page.
Insecure stylesheets & links — Checks <link> hrefs (typically CSS) served over http://. Stylesheets are active mixed content too — an intercepted stylesheet can inject hidden elements or restyle the page maliciously — so browsers block them, which can leave a page unstyled and broken.
Insecure iframes & media — Scans <iframe>, <audio>, <video>, and <source> tags for http:// sources. Insecure iframes are blocked (so embedded widgets, maps, or players vanish), while insecure media is downgraded or blocked depending on the browser.
Resource type breakdown — Lists each insecure resource with its tag type and URL so you know exactly what to fix and where. Active resources (scripts, stylesheets, iframes) are urgent because browsers block them; passive ones (images, media) are visible warnings to clean up.
Common issues we catch
Hardcoded http:// URLs in old content — Images and embeds added years ago — before the site moved to HTTPS — still carry absolute http:// URLs in the content. They survive the SSL switch and quietly break the padlock on every page that includes them. A search-and-replace across the database usually fixes them in bulk.
Third-party widgets that don't support HTTPS — An old chat widget, ad tag, analytics snippet, or embedded player that only offers an http:// URL forces insecure content onto your secure page. Browsers block these scripts, so the widget silently fails — find the vendor's HTTPS endpoint or replace the tool.
Scripts and stylesheets silently blocked — Because browsers block active mixed content (scripts, CSS, iframes) without an obvious message, the visible symptom is a page that looks broken or unstyled with no clear cause. The console shows the blocked URL — this checker surfaces it without you having to dig.
Protocol confusion in templates — Theme or template code that builds resource URLs with a hardcoded 'http://' prefix re-introduces mixed content on every page render, even after you clean the database. The fix is to use protocol-relative '//' or relative paths so resources inherit the page's scheme.
CDN or asset host not on HTTPS — Assets served from a CDN, image host, or subdomain that lacks its own valid certificate can only be loaded over http://. The main site is secure but its asset host isn't — moving the assets behind an HTTPS-capable host or your own domain resolves it.
Mixed content only on inner pages — The homepage is clean, so it looks solved, but blog posts, product pages, or landing pages built later still embed insecure resources. Mixed content is per-page — checking only the homepage misses the problem everywhere it actually lives.
Redirect-to-HTTPS hiding the real fix — Some servers auto-rewrite insecure resource requests to HTTPS, which papers over the symptom but adds a redirect round-trip per asset and fails for hosts that don't support HTTPS. The durable fix is correcting the source URLs, not relying on a rewrite.
Where this matters
All modern browsers — Chrome, Safari, Firefox, and Edge block active mixed content (scripts, stylesheets, iframes) automatically and downgrade or warn on passive content (images, media). The padlock disappears or shows a warning the moment a secure page loads anything over http://.
Google Search — HTTPS is a ranking signal, and a page undermined by mixed content presents as not-fully-secure to users — hurting trust and click-through. Clean, fully-secure pages avoid the soft conversion and trust drag that browser warnings cause.
WordPress — A classic source of mixed content after an SSL migration, because old posts store absolute http:// image and embed URLs in the database. A bulk search-and-replace from http:// to https:// across post content and settings clears most of it at once.
Shopify, Wix & hosted builders — Serve the storefront over HTTPS by default, but custom HTML embeds, third-party app snippets, and pasted code can still introduce insecure resources. The fix lives in the embed or app you added, not the platform's own assets.
Page builders & embedded widgets — Builders (Elementor, Divi) and embedded tools (maps, chat, video, ads) often inject resource URLs you don't directly control. When a widget is the source, you need its HTTPS variant or a replacement — this scan names the exact insecure URL to chase down.
Frequently asked questions
What is mixed content?
Mixed content is when a secure HTTPS page loads one or more resources — images, scripts, stylesheets, iframes, or media — over insecure http://. The page is encrypted, but those resources aren't, which undermines the security of the whole page and triggers browser warnings or outright blocking.
Why does mixed content break the padlock?
An insecure resource on a secure page can be intercepted or altered in transit, so the browser can no longer guarantee the page is fully safe. It removes or downgrades the padlock to signal that, and may block the insecure resource entirely — which can visibly break the page.
What's the difference between active and passive mixed content?
Active mixed content (scripts, stylesheets, iframes) can change the whole page, so browsers block it outright — that's why a page can suddenly look unstyled or have a missing widget. Passive mixed content (images, audio, video) only affects itself, so browsers usually load it but downgrade the padlock.
Does mixed content hurt SEO?
Indirectly but really. HTTPS is a Google ranking signal, and mixed content makes an HTTPS page present as not-fully-secure, complete with browser warnings that raise bounce rate and erode trust. Blocked scripts and styles can also break functionality crawlers and users rely on, compounding the harm.
How do I fix mixed content?
Change each insecure resource's URL from http:// to https://, confirm the resource is actually reachable over HTTPS, and for content you control use relative or protocol-relative ('//') paths so resources inherit the page's scheme. For third-party widgets, switch to the vendor's HTTPS endpoint or replace the tool.
I migrated to HTTPS but still see warnings — why?
Almost always because old content stores hardcoded http:// URLs that survived the migration, or a template builds resource URLs with an 'http://' prefix on every render. A bulk search-and-replace of http:// to https:// across your content and a check of your templates usually clears it.
Should I check more than the homepage?
Yes. Mixed content is per-page — a clean homepage doesn't mean inner pages are clean. Blog posts, product pages, and landing pages built at different times often carry their own insecure embeds. Check the page types that matter most, not just the front page.
Can a Content-Security-Policy help?
Yes. A CSP with the 'upgrade-insecure-requests' directive tells browsers to automatically retry http:// resources over https://, which can clear passive mixed content without editing every URL. It's a useful safety net, but correcting the source URLs is still the durable fix.
This is one of several free SEO tools from Custom Web Audits.
For a complete, prioritized analysis of your whole website,
run a full audit.
