What Is a Mixed Content Error?
A mixed content error occurs when a web page loaded securely over HTTPS also tries to load some of its resources, such as images, scripts, or stylesheets, over insecure HTTP. Because those insecure elements could be tampered with in transit, browsers either block them or downgrade the page's security indicator, removing the padlock and sometimes breaking features. It commonly appears after a site moves to HTTPS but still references old HTTP URLs. The fix is to update every resource link to HTTPS so the whole page loads securely.
- What it is
- An HTTPS page loading some resources over insecure HTTP (web.dev)
- Browser behaviour
- Active mixed content is blocked; passive content triggers warnings (web.dev)
- Common trigger
- Migrating to HTTPS while old HTTP URLs remain in content or theme
- Two types
- Active (scripts, iframes) is blocked; passive (images) is flagged (MDN Web Docs)
- Fix approach
- Update resource URLs to HTTPS or protocol-relative paths
What a mixed content error is #
A mixed content error happens when a page delivered securely over HTTPS also requests some of its resources over unencrypted HTTP, mixing secure and insecure content on the same page. The main document arrives safely, but individual pieces, an image, a script, a stylesheet, an embedded video, or a font, are pulled in over plain HTTP. Because those insecure requests travel unencrypted, they could be intercepted or altered by an attacker on the network, undermining the security the HTTPS page is supposed to guarantee. To protect users, browsers respond by blocking the dangerous resources or by downgrading the page's security indicator, often removing the padlock and showing a not fully secure notice (web.dev). The visible result can range from a missing padlock to broken images, unstyled pages, or features that stop working. It most often appears right after a site switches to HTTPS. Ensuring every resource loads securely is part of the HTTPS work on our /services/website-security page.
Active versus passive mixed content #
Browsers treat two kinds of mixed content differently based on how dangerous each is. Passive mixed content covers resources that display but cannot alter the rest of the page, chiefly images, audio, and video loaded over HTTP. Browsers usually still load these but flag the page as not fully secure, removing the padlock, because an attacker tampering with an image is less catastrophic. Active mixed content is far riskier: scripts, stylesheets, iframes, and fetch requests loaded over HTTP can control or rewrite the entire page, so an attacker who intercepts them could inject malicious code. For this reason browsers block active mixed content outright, which is why an insecure script or stylesheet can break a page's functionality or styling entirely (MDN Web Docs). Knowing which type you have explains the symptom: a flagged padlock points to passive content, while broken features or missing styles point to blocked active content. This distinction guides how urgently you must fix it, a nuance our /services/website-security team applies when auditing sites.
Why browsers block mixed content #
The reasoning behind mixed content warnings is straightforward security. The entire promise of HTTPS is that everything exchanged between a visitor and a site is encrypted and cannot be read or altered in transit. If a supposedly secure page then loads even one resource over plain HTTP, that resource becomes a hole in the protection: an attacker positioned on the network could intercept or replace it. For a script or stylesheet, that means potentially hijacking the whole page. Allowing mixed content would let sites appear secure while quietly exposing users, so browsers refuse to pretend. By blocking active content and flagging passive content, they make the compromise visible and limit the damage. This is why you cannot simply ignore the warning and expect full protection; the padlock only means something if the whole page is genuinely secure (web.dev). Understanding this rationale helps site owners see mixed content as a real security gap to close, not a cosmetic nuisance, which is how we treat it on our /services/website-security page.
Common causes after an HTTPS migration #
Mixed content most often surfaces immediately after a site moves from HTTP to HTTPS, because the switch flips the page address to secure but leaves countless resource links still written as HTTP. WordPress sites are especially prone, since old posts and pages hard-code image and media URLs, themes and plugins reference scripts and stylesheets by absolute HTTP paths, and settings may still store the HTTP site address. Embedded third-party content, an ad, a widget, a map, or a video, can also arrive over HTTP if the provider or the embed code specifies it. Even a stylesheet loading an HTTP web font counts. Because these references are scattered across content, code, and settings, a migration that only changes the main address inevitably leaves mixed content behind unless every URL is updated. This is exactly why migrations need careful handling rather than a simple protocol flip. Our /services/website-migrations team updates internal URLs comprehensively when moving sites to HTTPS so mixed content does not appear.
Finding and fixing insecure URLs #
The practical fix is to locate every HTTP resource on your HTTPS pages and update it to HTTPS. Browser developer tools list mixed content in the console, naming each offending URL, and there are online scanners that crawl a site for insecure resources. For WordPress, a database search-and-replace updates hard-coded HTTP links across all content at once.
# WordPress: safely replace hard-coded HTTP URLs with HTTPS
# (WP-CLI handles serialized data correctly - do NOT use raw SQL)
# 1. Dry run first to see what would change:
wp search-replace 'http://example.com' 'https://example.com' --dry-run
# 2. Apply the replacement across all tables:
wp search-replace 'http://example.com' 'https://example.com' --all-tables
# 3. Flush caches so old HTTP references are not served:
wp cache flush
# In HTML/CSS you can also use protocol-relative or absolute HTTPS:
# <img src="//example.com/logo.png"> (matches page protocol)
# <img src="https://example.com/logo.png">Handling third-party and embedded content #
Some mixed content comes not from your own files but from external resources you embed. An advertisement, a social media widget, a chat tool, a map, an analytics script, or a video player may load over HTTP if its code or provider specifies it. Because you do not control those servers, the fix differs from updating your own URLs. First, check whether the provider offers an HTTPS version of the resource, which most reputable services now do; simply switching the embed code to the HTTPS endpoint resolves it. If a provider only serves content over HTTP, that service is outdated and insecure, and the right move is to replace it with a modern alternative rather than weaken your page. Avoid workarounds that try to force insecure content through, since they reintroduce the exact risk the browser is preventing. Auditing embeds is easy to overlook because the resources are not in your codebase, yet they trigger the same warnings. Our /services/website-security team reviews third-party embeds as part of securing a site end to end.
Using Content-Security-Policy to enforce HTTPS #
Beyond fixing individual URLs, you can instruct browsers to upgrade or block insecure requests automatically using HTTP response headers. The upgrade-insecure-requests directive tells the browser to load any HTTP resource over HTTPS instead, which cleanly resolves passive references without editing every link, provided the resource is actually available over HTTPS. A broader Content-Security-Policy can also block mixed content and report violations, giving you visibility into what is still insecure. These headers are a powerful safety net, but they are best used alongside, not instead of, fixing the underlying URLs, because a header cannot conjure an HTTPS version of a resource that only exists over HTTP. Configuring them requires care to avoid inadvertently blocking legitimate resources, so testing on a staging copy first is wise. Used well, they harden a site against future mixed content creeping back in as content is added. Setting up these security headers correctly is part of the hardening work covered on our /services/website-security page for client sites.
Mixed content and third-party scripts over time #
Even after a clean HTTPS migration, mixed content can reappear as a site evolves, so ongoing vigilance matters. Every time someone adds an image, embeds a video, pastes in a widget, or installs a plugin that loads external resources, there is a chance an insecure HTTP link slips in. Marketing tags, chat tools, and advertising scripts are especially common offenders because they are added quickly and often copied from older documentation. The practical habit is to check the browser console and the padlock on any page after adding new content or a new tool, catching a stray HTTP resource immediately rather than weeks later. Choosing reputable providers that serve everything over HTTPS avoids most recurrences, and security headers such as upgrade-insecure-requests act as a backstop for anything missed. Periodic scans of the whole site catch insecure resources that accumulate unnoticed. Treating mixed content as an ongoing maintenance item, not a one-time migration fix, keeps the padlock intact permanently. Our /services/care-plans include regular checks that catch mixed content and other security regressions before they affect visitors.
Preventing mixed content going forward #
Keeping a site free of mixed content is mostly about discipline after going HTTPS. When migrating, update every internal URL across content, themes, plugins, and settings rather than only the main address, and verify with a scan afterward. Use HTTPS or protocol-relative links whenever you add images, scripts, or embeds, and choose third-party providers that serve content securely. Add security headers such as upgrade-insecure-requests as a safeguard against stray HTTP references. After any change, check the browser console and the padlock on key pages to confirm everything loads securely. Because mixed content both weakens security and can visibly break pages, it deserves prompt attention, and because HTTPS is a ranking and trust signal, a clean secure page also supports your visibility (web.dev). When a migration or ongoing content work introduces these warnings, fixing them thoroughly protects both users and your reputation. Our /services/website-migrations and /services/website-security teams eliminate mixed content during moves and keep sites fully secure afterward.
FAQ
What is a mixed content error in simple terms?
It means a secure HTTPS page is loading some of its parts, like images, scripts, or stylesheets, over insecure HTTP. Because those parts are not encrypted, the browser either blocks them or removes the padlock and warns the page is not fully secure. The fix is to update every resource so the whole page loads over HTTPS.
How do I fix mixed content errors?
Find every insecure resource using your browser's developer console or an online scanner, then update each HTTP link to HTTPS. On WordPress, run a safe database search-and-replace to convert hard-coded URLs. Switch embedded third-party content to its HTTPS version, and add an upgrade-insecure-requests header as a safeguard. Clear all caches afterward and recheck the padlock.
What is the difference between active and passive mixed content?
Passive mixed content is display-only resources like images, audio, and video loaded over HTTP; browsers usually still show them but flag the page as not fully secure. Active mixed content is scripts, stylesheets, and iframes that can control the page; browsers block these outright because they are far more dangerous, which can break styling or features.
Why does my padlock disappear after switching to HTTPS?
Because your pages still reference some resources over HTTP even though the main address is now HTTPS. Those insecure requests are mixed content, so the browser removes the full-secure padlock. This is very common after a migration that changed only the site address. Updating every image, script, and embed link to HTTPS restores the padlock.
Can mixed content break my website?
Yes. When active mixed content like scripts or stylesheets is blocked by the browser, features can stop working and pages can lose their styling entirely. Passive content like images may still load but with a security warning. Either way the page is compromised in appearance or security, so fixing insecure resource links is important for both function and trust.
Does mixed content affect SEO?
Indirectly, yes. HTTPS is a trust and ranking signal, and a page flagged as not fully secure undermines it, while broken features from blocked content raise bounce rates and hurt engagement. Search engines prefer fully secure pages, so eliminating mixed content supports both your rankings and the user experience. It also keeps the padlock intact, which reassures visitors.
How Local Web Advisor checks this for you
Is your own website getting security & compliance right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for security & compliance and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?