Mixed Content Error: What It Is and How to Fix It

What is a mixed content error?

A mixed content error happens when a page loads over secure HTTPS but pulls at least one resource, such as an image, script or stylesheet, from an insecure HTTP address. The browser then blocks that resource or drops the secure padlock. As a result, the page looks broken and visitors lose trust in the site.

The name comes from the mix of secure and insecure connections on a single page, so it is easy to remember. However, the page itself arrives encrypted while one piece travels in plain text. Therefore, anyone who can watch or change that traffic can alter how the page looks or behaves.

In the browser console, the error also usually starts with the words "Mixed Content". The message says the page was loaded over HTTPS but requested an insecure resource. For example, an old blog post with an image tag that points to an http:// address will trigger it.

This guide does not explain from scratch what an SSL certificate is. We covered that in our guide to SSL certificates and HTTPS security. Instead, we focus on why the error appears even when the certificate works, and how you clear it.

Who is responsible for a mixed content error: the visitor, the site owner or the server admin?

If you are a visitor, you did nothing wrong. The error comes from HTTP addresses in the page source. Therefore, the site owner or the technical person behind the site fixes the content, and the server admin steps in for redirects and security headers. Work out your own role first, because looking in the wrong place only wastes time.

If you use a hosting package, your provider controls part of the server settings. Therefore, opening a support ticket is the right move for any setting you cannot reach in the panel. Likewise, if an agency or developer built the page, they should correct the addresses in the source code.

What is the difference between passive and active mixed content?

Passive mixed content covers images, video and audio that do not interact with the page. Active mixed content covers scripts, stylesheets and iframes that can change how the page behaves. According to web.dev, an attacker can take control of the whole page through active content. Because of that risk, modern browsers block active content by default.

This split follows the classification in the MDN documentation. In practice, a clean-looking image does not prove the page is clean. The browser may have upgraded it silently, so check the source too. A script on the same page, however, stays HTTP and gets blocked, so features stop working.

What causes a mixed content error in the first place?

First, know that the cause is almost always an http:// address left over from the past. If the site went live on HTTP, content written back then carries the old addresses. Later you install a certificate, so the page becomes HTTPS while the content stays the same. For that reason, older sites hit the problem more often than new ones.

• Post, image and embed addresses left over from the HTTP era.
• Hard-coded http:// addresses in the theme or custom CSS.
• Content copied and pasted from another website.
• Old domain names or resource URLs saved in plugin settings.
• HTTP addresses set up for a CDN or a subdomain.
• Insecure links that arrive through comments, forms or user content.

Knowing the cause also tells you where to fix it. For example, addresses inside posts need a database replace. Addresses in the theme, however, need a file edit. A proxy-related problem needs a server setting instead.

Why do browsers block mixed content?

The block exists so that one weak link does not undo the protection HTTPS gives. A file that arrives over HTTP can be read or changed on the way. MDN describes this as eavesdropping and man-in-the-middle (MITM) attacks. If an attacker swaps a script, the whole page is exposed.

The risk is lower with passive content, but it is not zero because attackers can still swap files. For example, a swapped image can show misleading information. Besides, the request itself can leak which page the visitor is on. So browsers first try to upgrade the resource, and if that fails they warn or block.

As a site owner, take one lesson from this: move the resource to HTTPS instead of hiding the warning. Hiding a browser warning adds no security at all.

How do you find a mixed content error in the browser console?

First, open the page over HTTPS in Chrome, press F12 and look at the Console and Issues tabs. According to web.dev, the Issues tab lists every insecure resource and says whether it was blocked. Firefox and Safari write messages to the console instead. Then work through these steps.

1. Open the page in a private window, because extensions can clutter the console.
2. Open the developer tools and hard-reload the page.
3. Search the Console tab for the phrase "Mixed Content".
4. Note the address and type of each insecure resource in the Issues tab.
5. Open the page source (Ctrl+U) and search for "http://".

Once you have the address, then work out where it comes from. If it sits in the content, you edit the post. When it comes from the theme, you check the theme files. If a plugin adds it, then you check the plugin settings. When one address repeats on many pages, you need a bulk fix, which we cover below.

A console message carries three facts: the page you are on, the resource requested and the resource type. The type tells you whether the content is passive or active. Expect lost features with active types, because the browser stops the code. Meanwhile, many lines from the same domain point to one setting as the source.

Which pages with a mixed content error should you fix first?

With thousands of pages, cleaning everything at once is unrealistic, so prioritize. Set the order by the damage the error does to visitors and revenue. Pages that take money or personal data come first. Next come the pages with the most traffic. Finally, archive content comes last.

The bulk replace often closes the fourth group by itself. So verify the first two groups by hand, then run the bulk job. This order protects the riskiest pages from day one.

How do you scan a whole site for a mixed content error?

Finding one page is easy, but walking through hundreds of pages by hand is slow. Therefore, combine crawling tools with a database search. MDN lists tools such as LinkChecker and mcdetect for this check. In addition, searching your own content for "http://" in the database often exposes most sources quickly.

• Crawl your pages with a tool and list the HTTP resources.
• Count the content and meta records that contain "http://" in the database.
• Search theme and plugin files for hard-coded addresses.
• Confirm that your sitemap and canonical addresses use HTTPS.

If you also want to clean up dead links, our broken link checker makes that job easier. If you are unsure what platform a site runs on, the website technology checker helps you choose the right fix.

Is your certificate and HTTPS redirect working before you start?

Before you clean up mixed content, confirm that the certificate is valid. An expired certificate, or one issued for the wrong domain, produces a different warning. That warning is a full-page browser error instead of a line in the console. Mixing up the two problems ruins the diagnosis.

Also, you can check the certificate status with our SSL checker. If you run many subdomains, our guide to a wildcard SSL certificate explains which certificate type you need. A subdomain that the certificate does not cover can be a mixed content source on its own.

Next, test that the HTTP address redirects to HTTPS. Without a redirect, the same content lives at two addresses and some visitors open the insecure one. We cover the redirect setup in the server section, because it needs its own examples. For the SEO side of redirects, see our guide to the redirect chain problem.

What is the right order of steps to fix a mixed content error?

Order matters, because a fix in the wrong order creates rework. First you verify the certificate, then you fix the source, and last you add the safety net. Check the console again after every step. That way you see which step actually worked, so you avoid guesswork.

1. Verify that the certificate is valid and HTTP redirects to HTTPS.
2. List the insecure resources in the console and group them by type.
3. Take a backup, then replace the addresses in content in bulk.
4. Fix addresses in the theme, plugins and custom code by hand.
5. Use the HTTPS version of external resources, or remove the resource.
6. Add the CSP upgrade-insecure-requests header as a safety net.
7. Clear every cache and test the pages again.

The sections below walk through these steps in order. On large multilingual sites, plan separate time for each step.

How do you fix a mixed content error in WordPress?

In WordPress, the first step is to confirm that the "WordPress Address" and "Site Address" fields under Settings, General start with https://. Because these two fields are the base for the addresses that your theme and plugins generate. If they still say http://, many resources come out insecure. You may also need to log in again after you change them.

Next, check the theme and plugins. Hard-coded http:// addresses can remain in theme settings, in the customizer or in page builder plugins. For example, look at the logo, background images and custom CSS one by one. Some of these addresses sit in places that a database replace does not touch.

• Confirm that both general settings addresses start with https://.
• Check the logo and background addresses in the theme customizer.
• Search custom CSS and widget areas for http:// addresses.
• Update old addresses saved in plugin settings.
• Clear the cache plugin and the CDN cache.

If you are still deciding on the overall architecture, our comparison of WordPress vs a custom website gives you a frame. Also, always take a backup before you change settings. For a backup plan, see our website backup strategy guide.

How do you replace http:// addresses in the database in bulk?

Old addresses in content live in the database, so a bulk fix needs a search and replace. For WordPress, the safest route is the WP-CLI search-replace command. According to the WP-CLI documentation, the command handles PHP serialized data intelligently and does not change primary key values. A plain SQL REPLACE can corrupt serialized data, so we do not recommend it.

First take a database backup, then simulate the change. In the example below, you simply replace example.com with your own domain. You run the commands over SSH in the WordPress folder.

wp db export before-change.sql
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

The first command writes the backup to a file. The second shows a report with --dry-run but saves nothing to the database. If the report shows the number of changes you expect, then you run the third command. The --skip-columns=guid option protects the permanent identifier addresses of your posts. This example follows the command structure in the WP-CLI documentation.

You may need to replace the www and non-www versions of the domain separately. Besides, the --all-tables option widens the scope when your table prefix differs. It touches every table, so use it only when you have a backup.

Is it safe to fix mixed content with a plugin?

A plugin is a quick patch, not a permanent fix. Some plugins rewrite http:// addresses to https:// in the page output on every request. This hides the problem, but it does not fix the source. When you remove the plugin, the error returns, and the plugin adds a small processing cost to every page.

Database search-and-replace plugins do from the dashboard what WP-CLI does from the command line. Also, choose one that supports serialized data, and take a backup before you run it. We do not promote a specific product, because the right choice depends on your site setup.

In short, the healthiest order is this: fix the source first, then add the CSP header as a safety net. Use a plugin only during the transition.

How does CSP upgrade-insecure-requests fix a mixed content error?

The upgrade-insecure-requests directive is a Content-Security-Policy setting that tells the browser to treat every http:// address as if it were https://. According to MDN, the directive is designed for sites with many legacy insecure URLs. It upgrades both first-party and third-party subresources. As a result, you do not have to correct every address in the code one by one.

Content-Security-Policy: upgrade-insecure-requests;

You can add the header in the server configuration. A meta tag in the HTML also works, but the header is the sturdier route. On Apache, for example, one line is enough when mod_headers is on. On Nginx, you also write a single line. The example shows only the directive value, so adapt it to your own configuration.

# Apache (needs mod_headers)
Header always set Content-Security-Policy "upgrade-insecure-requests"

# Nginx (inside the server block)
add_header Content-Security-Policy "upgrade-insecure-requests" always;

Know the limit: if the resource does not exist over HTTPS, the request fails and the browser does not fall back to HTTP. The directive also does not replace HSTS. Specifically, MDN advises setting the Strict-Transport-Security header separately to stop SSL stripping on top-level navigation. For testing, you can run the Content-Security-Policy-Report-Only header alongside.

Does an .htaccess or server redirect fix a mixed content error?

No, not on its own. An HTTP to HTTPS redirect makes sure the visitor enters the page over HTTPS. The http:// resource addresses inside the page, however, are judged by the browser itself. The browser blocks a blockable resource without ever asking the server. So a redirect is necessary but not sufficient.

The Apache documentation recommends a Redirect in a dedicated HTTP virtual host as the cleanest way to force HTTPS. If you cannot reach the server configuration, there is a mod_rewrite alternative for .htaccess. On Nginx, you use return 301.

# Apache virtual host (preferred)
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

# Apache .htaccess alternative
RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

# Nginx
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

The Apache examples come from the "Forcing HTTPS" recipe in the official documentation. The 301 code tells search engines that the HTTPS version is the permanent address. web.dev gives the same advice. If you hit a redirect loop, the usual cause is a CDN or proxy in front of a server that cannot detect HTTPS.

What is the relationship between mixed content and HSTS?

HSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS. According to web.dev, it keeps HTTPS in use even when a visitor follows an http:// link, and it prevents SSL stripping attacks. It also cuts the redirect delay.

HSTS does not solve mixed content on its own, because it does not fix the resource addresses inside the page. It does, however, secure top-level navigation. CSP upgrades cover subresources, while HSTS covers page entry. In short, the two complement each other.

Be careful, though: turning on HSTS is hard to undo. The browser remembers the rule for the set period, so mistakes last. If you apply the rule to subdomains and one of them does not serve HTTPS, visitors cannot reach it. So test with a short period first, and make sure every subdomain works over HTTPS. If you are unsure, ask your provider about this setting.

How does mixed content appear behind a CDN, reverse proxy or load balancer?

If a CDN or load balancer ends HTTPS and then talks to your server over HTTP, the application may think it runs on HTTP. In that case, applications such as WordPress then generate page addresses with http://. The visitor arrives over HTTPS, but the addresses inside are insecure. That is how mixed content appears.

The WordPress documentation gives a configuration example for this case that reads the proxy header. If the server sees https in the X-Forwarded-Proto header, it tells the application it is on HTTPS. You adapt the example in wp-config.php to your own infrastructure.

define( 'FORCE_SSL_ADMIN', true );
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

If you put this code in the wrong place, you may lock yourself out of the admin area. Therefore, copy the file first. Your CDN panel may also offer HTTPS redirect and automatic rewrite options. The option names vary by provider, so check your provider's documentation.

How do you fix a mixed content error from external resources?

External resources are outside your control, so they need a separate strategy. For example, fonts, ad code, widgets, embedded video and old partner links fall into this group. First, try the address with https:// to see whether an HTTPS version exists. Most providers serve HTTPS today, so changing the address is often enough.

• If an HTTPS version exists, update the address to https://.
• Refresh embedded iframe addresses from the provider's current embed code.
• Remove a resource with no HTTPS support, or replace it with an equivalent.
• If the license allows it, host the file yourself.

If no HTTPS version exists, the CSP upgrade does not help either, because the request fails. Keeping such a resource on the site is therefore risky for both security and function. For the wider security picture, see our OWASP Top 10 guide.

Why does a mixed content error show up more often on ecommerce sites?

On an ecommerce site, content does not come from one place, so old addresses are more likely to survive. Product images may come from a supplier XML file, descriptions from a bulk import and banners from campaign tools. Also, each channel carries its own address format. For example, a product image you imported may be saved with http://.

The error costs more on cart and checkout pages, because a visitor who sees a warning may abandon the payment. If the payment provider's embedded form is called over HTTP, the form may not load at all. So test the cart, checkout and account pages separately.

For the speed and conversion side, read our article on whether ecommerce page speed affects sales. If you want to handle the technical and commercial sides of your shop together, our ecommerce consulting service covers these topics.

How do you confirm that the mixed content error is gone?

However, verification does not mean checking only the home page. Test different page types and different devices. A cache can keep showing the old version, so clear the cache before every check. Then follow the list below in order.

1. Clear the site cache and the CDN cache.
2. Open the home page, a post, a product and the cart in a private window.
3. Confirm that the Console and Issues tabs are clean on every page.
4. Check that the padlock icon shows in full.
5. Retest at least one page on a mobile device.
6. Check the HTTPS property and the sitemap in Search Console.

On the search side, our Google Search Console guide shows you how to read the reports. Canonical tags, internal links and sitemap addresses should also use HTTPS. Otherwise, search engines keep crawling the old version.

When should you not fix a mixed content error yourself?

To be honest, in some cases it is wiser to hand the problem to your hosting provider or an experienced developer. We are a digital marketing and web team instead of a hosting company. Also, the commands in this guide follow official documentation. Even so, a wrong command on a live site can do real damage.

• Without a database backup, do not run a search and replace.
• Lacking SSH access or command-line experience, ask your provider for support.
• On shared hosting, open a ticket when you cannot set the server header.
• When the checkout page broke, try the change on a staging copy first.
• If you are unsure what changed in wp-config.php or a server file, stop.

Your hosting choice makes this job easier or harder. For details, see our guide on how to choose web hosting. For firewall-related blocks, our article on ModSecurity and 403 errors can also help.

Which habits prevent a mixed content error in the future?

In practice, the cheapest fix is never creating the problem. When you add new content, write every address with https://. You can also use relative addresses for resources on the same domain. Also, make the console check a routine after big jobs such as a migration or a theme change.

• Check the console in preview before you publish new content.
• Pick the HTTPS version of every embed code you take from outside.
• Keep the CSP upgrade-insecure-requests header as a safety net.
• Consider collecting violation reports in Report-Only mode.
• Review addresses before you move a staging change to production.

If you want to manage technical cleanup, SEO and design decisions together, our SEO consulting and web design services work in that frame. When a topic needs expertise, our team supports the process. For sources, the MDN mixed content documentation and the web.dev mixed content guide are good starting points. This guide is not legal or corporate security advice.