What Is a Mixed Content Warning?
A mixed content warning appears when a secure HTTPS web page loads some resources, like images, scripts, or stylesheets, over insecure HTTP. Because part of the page travels unencrypted, the browser flags the page as not fully secure, showing a warning icon instead of the padlock, and often blocking the insecure elements. Mixed content undermines the protection of HTTPS and commonly appears after a site migrates to SSL but still references old HTTP URLs in its code.
- What triggers it
- An HTTPS page loading resources over insecure HTTP
- Two categories
- Active mixed content (scripts, iframes) is blocked; passive (images) may load with a warning (browser behavior)
- Common cause
- Hardcoded HTTP URLs left after an SSL migration (industry-typical)
- The fix
- Update all resource URLs to HTTPS or protocol-relative paths (developer best practice)
What is a mixed content warning? #
A mixed content warning is the browser's way of telling you that a page delivered over a secure HTTPS connection also pulls in some resources over insecure, unencrypted HTTP. When a page loads, it is not just one file; it assembles images, stylesheets, fonts, scripts, videos, and other assets, each fetched by its own request. If the page itself is HTTPS but one of those assets is requested over plain HTTP, the page becomes a mix of secure and insecure content, which is exactly what the term describes. Browsers respond by removing the reassuring padlock, showing a not fully secure or warning indicator, and, for the riskier kinds of content, refusing to load the insecure resource at all. The warning matters because HTTPS only fully protects a page when everything on it is encrypted; a single HTTP asset creates a gap. Mixed content is extremely common after a site moves to SSL, and understanding it starts with understanding HTTPS itself, covered at /wiki/what-is-an-ssl-certificate.
Why does mixed content undermine security? #
The whole point of HTTPS is to encrypt the connection between a visitor's browser and the website, so that no one in between, on public Wi-Fi, at an internet provider, or anywhere along the path, can read or tamper with the data. Mixed content punches a hole in that protection. When even one resource loads over HTTP, that request and response travel in the clear, and an attacker positioned between the user and the server can see it or, worse, modify it. This is not merely theoretical. If the insecure resource is a script, an attacker can replace it with malicious code that then runs with full access to the supposedly secure page, capturing form data, hijacking sessions, or injecting content, effectively defeating the encryption entirely. Even an insecure image can be swapped or used to leak information about the user's activity. Because the browser cannot guarantee the integrity of the whole page when part of it is unprotected, it downgrades the security indicator. Fixing mixed content restores the end-to-end protection your SSL certificate is meant to provide, a core concern of /services/website-security.
What is the difference between active and passive mixed content? #
Browsers treat mixed content in two categories based on how dangerous it is. Active mixed content includes resources that can control or change the page, such as scripts, stylesheets, iframes, and XMLHttpRequest or fetch calls. Because a compromised script or stylesheet could take over the entire page, browsers block active mixed content outright by default; the insecure resource simply does not load, which often breaks functionality or layout, making the problem obvious. Passive mixed content includes resources that only display and cannot alter the rest of the page, such as images, audio, and video. These are considered lower risk, so browsers historically allow them to load but still strip the padlock and show a warning, because an attacker could still swap the image or observe the request. Modern browsers increasingly try to upgrade passive requests to HTTPS automatically and are moving toward blocking more insecure content over time. The practical upshot is that active mixed content usually breaks something visible, while passive mixed content quietly downgrades your security indicator, and both should be eliminated.
Why does mixed content appear after an SSL migration? #
The most common time mixed content warnings surface is right after a site switches from HTTP to HTTPS, and the reason is straightforward. Over the life of a website, developers and content editors hardcode many absolute URLs into the site: image sources in posts, script and stylesheet links in the theme, embedded videos, font references, and links added through page builders. When those URLs were written with an http:// prefix, they keep pointing to the insecure version even after the site as a whole moves to HTTPS. The main pages load securely, but each hardcoded HTTP asset triggers mixed content. The problem hides in several places at once: the database that stores post and page content, theme and plugin files, configuration settings, and third-party embeds. This is why a migration is not finished the moment the certificate is installed; the entire site must be scanned and every insecure reference updated. Rushing this step is a frequent cause of broken layouts and lingering warnings, which is why we handle it methodically as part of /services/website-migrations.
How do you find and fix mixed content? #
Fixing mixed content is a systematic hunt for every HTTP reference. The fastest way to see what is wrong is the browser's developer console, which lists each mixed content warning and the exact URL of the offending resource. Online scanners and crawlers can check an entire site and report every insecure asset across many pages. Once you know the sources, the fix is to change each resource URL from http:// to https://, provided the resource is also available securely, which nearly all modern services are. In a content management system, this usually means updating the database where content is stored, often with a careful search-and-replace of old HTTP URLs, plus editing theme and configuration files and re-checking third-party embeds. Setting the site's canonical URLs to HTTPS and updating any hardcoded settings prevents new links from being generated insecurely. As a backstop, the Content-Security-Policy directive upgrade-insecure-requests tells browsers to automatically request HTTP assets over HTTPS, catching stragglers. Because a database-wide replace can go wrong, it should be done with a backup in place; our /services/website-security and /services/website-migrations teams do this safely.
How does mixed content affect SEO and performance? #
Mixed content is not only a security issue; it also touches search rankings, trust, and speed. Google uses HTTPS as a ranking signal and, more importantly, browsers that display not secure or warning indicators erode visitor trust, increasing bounce rates and hurting conversions, especially damaging for local businesses whose sites exist to win calls and bookings. When active mixed content is blocked, essential scripts or styles may fail to load, breaking navigation, forms, or layout, which directly harms usability and can tank conversions. There is a performance angle too: some browsers attempt to upgrade or retry insecure requests, adding overhead, and broken resource loading can leave pages half-rendered. A fully secure, warning-free site loads predictably and signals professionalism. Because these concerns overlap, resolving mixed content is often bundled with broader tuning; our /services/speed-optimization work frequently uncovers and fixes insecure references while improving load times. Ensuring every page is clean HTTPS supports both the technical SEO baseline and the user experience that turns visitors into customers.
What role does HTTPS redirection play? #
Fixing individual mixed content references solves the assets, but a complete solution also ensures the whole site consistently uses HTTPS at the connection level. A proper setup redirects all HTTP requests to their HTTPS equivalents with a permanent 301 redirect, so anyone arriving at an old insecure URL is immediately and safely sent to the secure version. Beyond that, HTTP Strict Transport Security, or HSTS, is a header that instructs browsers to only ever connect to your site over HTTPS, even if a user types http:// or clicks an old link, eliminating an entire class of downgrade risks and preventing many mixed content scenarios from occurring in the first place. Together, site-wide HTTPS redirection and HSTS make the secure connection the only option, so the browser never even attempts an insecure request for the main document. These configurations live at the server or CDN level and are part of a correct SSL deployment, explained further at /wiki/what-is-an-ssl-certificate. We configure redirection and HSTS as standard when we migrate or secure a site through /services/website-migrations, closing the gap that mixed content warnings expose.
How can you prevent mixed content going forward? #
Preventing mixed content is easier than chasing it after the fact, and it comes down to a few habits. First, always reference resources with HTTPS URLs, or better, use relative paths so assets inherit the page's secure protocol automatically and never hardcode an insecure prefix. Second, when adding third-party embeds, widgets, fonts, or scripts, confirm the provider offers HTTPS, which virtually all reputable services now do, and use their secure URLs. Third, deploy the upgrade-insecure-requests Content Security Policy directive as a safety net so any stray HTTP request is automatically upgraded by the browser. Fourth, enforce site-wide HTTPS with redirects and HSTS so the secure protocol is the default everywhere. Finally, include a mixed content check in your routine maintenance, since a new plugin, an edited page, or an embedded resource can reintroduce insecure references at any time. Ongoing monitoring catches these before customers or search engines do. For businesses without in-house developers, folding these checks into a maintenance subscription is the simplest safeguard, and we build them into /services/website-security so your padlock stays intact.
FAQ
What causes a mixed content warning?
A secure HTTPS page that loads at least one resource, such as an image, script, stylesheet, or iframe, over insecure HTTP. Because part of the page travels unencrypted, the browser flags it as not fully secure. It most often appears after a site moves to HTTPS but still references old hardcoded HTTP URLs.
Is mixed content a serious security problem?
Yes. HTTPS only fully protects a page when every resource is encrypted. An insecure resource can be intercepted or, if it is a script, replaced with malicious code that runs on the secure page, defeating the encryption. Even insecure images undermine integrity, which is why browsers downgrade the security indicator.
What is the difference between active and passive mixed content?
Active mixed content, like scripts, stylesheets, and iframes, can control the page, so browsers block it by default, often breaking functionality. Passive mixed content, like images and video, only displays, so browsers may load it but still show a warning and strip the padlock. Both should be eliminated.
How do I fix mixed content warnings?
Use the browser developer console or an online scanner to find every insecure resource, then change each URL from http:// to https://. In a CMS this usually means a careful database search-and-replace plus editing theme files, done with a backup. Add the upgrade-insecure-requests policy as a backstop.
Why did mixed content appear after I installed SSL?
Installing the certificate secures the connection, but many resource URLs were hardcoded with http:// in your content, theme, settings, and embeds over the site's life. Those keep pointing to insecure versions until updated. A migration is not complete until every insecure reference is found and changed to HTTPS.
Does mixed content affect SEO?
Indirectly, yes. Google favors HTTPS, and not-secure warnings erode visitor trust, raising bounce rates and hurting conversions. Blocked active mixed content can break scripts, forms, or layout, damaging usability. A clean, warning-free HTTPS site supports both your technical SEO baseline and the user experience that drives calls and bookings.
Was this helpful?