What are 'mixed content' errors and how do I resolve them?

What is a mixed content warning? 

A mixed content warning appears in a user’s browser when the site they’re trying to visit is loading HTTPS and HTTP scripts or content at the same time. This can cause problems since HTTP and HTTPS are completely separate protocols.

When you migrate to HTTPS, everything needs to be running over that protocol, including your images, JavaScript files, and so on. Below are some examples of what can happen if some of your content is still loading over HTTP instead.

Mixed Content Warning Examples:

Of course, not everyone is using Chrome.

Here is an example of what happens in Firefox when a mixed content warning displays on a site:

What Causes Mixed Content Warnings?

We’ve found that most common mixed content warnings appear right after someone migrates their site from HTTP to HTTPS. Some HTTP links simply get carried over, and this causes mixed content warnings to start firing.

Here are some additional causes of this warning:

• You just added a new service or plugin to your site. In particular, developers sometimes use absolute paths (http://yourdomain.com/style.css) in their plugins or themes to link to CSS and JavaScript, instead of using relative paths (/style.css).
• Your images have hardcoded URLs (such as http://yourdomain.com/image.png) that run over HTTP. These could be within posts, pages, or even widgets.
• You’re linking to HTTP versions of external scripts (hosted jQuery, Font Awesome, etc.).
• You have embedded video scripts that use HTTP instead of HTTPS.

Unfortunately, you may not uncover the real source of the issue until you start troubleshooting.

With that in mind, let’s take a look at some methods you can use to fix mixed content warnings.

How to Fix Mixed Content Warnings (4 Steps)

You can follow the four simple steps below to fix your mixed content warnings. This process assumes that you have already done the following:

- Installed an SSL certificate
- Redirected HTTP to HTTPS (site-wide)

We’ll be using an example development site in the following examples.

1. Find Out Which Resources Are Loading Over HTTP

The first thing you’ll need to do is find out which resources are still loading over HTTP.

Remember that these warnings might only be happening in certain areas of your site, not globally. Browse to the page that’s prompting the warning and launch Chrome DevTools by hitting:

• Windows: F12 or CTRL + Shift + I
• macOS : Cmd + Opt + I

You can also open Chrome DevTools from the tools menu in your browser:

There are a couple of places you can check to find out which resources aren’t loading over HTTPS.

The first is the Console tab. Note that you might need to refresh the page after you have Chrome DevTools open for it to properly load everything.

If mixed content errors are present, they’ll be highlighted in either red or yellow. Typically, they’re accompanied by information explaining that “This request has been blocked; the content must be served over HTTPS.” This means that the browser settings are configured to automatically block any HTTP content.

In an effort to ensure pages only load over HTTPS, Chrome started to begin blocking mixed content by default with Chrome 79. Most recently, they unrolled features to start auto-upgrading mixed images and media.

Therefore, when using Chrome DevTools, you may see mixed content messages indicating some requested elements were automatically upgraded:

Here, we can clearly see that there are a variety of insecure elements causing the mixed content warnings, including a stylesheet and script.

You’ll also notice that a request was made for an insecure .jpg image, which was automatically upgraded to HTTPS. (Note: If this were in another browser other than Chrome, it wouldn’t be automatically upgraded).

You can also look in the Security tab of Chrome DevTools. This will show you any non-secure origins:

Under the Network tab, you can also find a list of blocked requests:

If you aren’t using Chrome, or you just want a quick summary of the errors, you can also use a free tool like Why No Padlock.

It scans an individual page and shows you all of the insecure resources:

This tool is easy to use. You can simply enter your URL and click on Test Page, and it will show you any errors that are present. Plus, it’s free!

2. Verify Whether HTTP Resources Are Accessible Over HTTPS

The next step is confirming that the resources loading over HTTP are accessible over HTTPS. They most likely are, you just need to update the links.

As an example, let’s say our mixed content errors pointed to the following insecure jQuery script and .jpg image:

• http://ajax.googleapis.com/ajax/libs/jquery/3.31/jquery.min.js
• http://example-site.com/wp-content/50d00acf6e4%2Fpuppy-thumb.jpg?v=1600261043278

If we take both of those URLs, input them into our browser’s address bar, and replace “http” with “https” at the beginning, we can see that they load just fine. Therefore, we simply need to do a search and replace on our site.

3. Perform a Search and Replace

One popular solution you can use for this is Better Search Replace:

The Better Search Replace plugin is developed by the WordPress team over at Delicious Brains, and is inspired by the interconnect/it PHP script, which we’ll mention in the next method.

Some of Better Search Replace’s features include:

• Serialization support for all tables.
• The ability to select specific tables.
• The option to conduct a ‘dry run’ to see how many fields will be updated.
• No server requirements, aside from a running installation of WordPress.
• WordPress multisite compatibility.

Another method you can use to perform a WordPress search and replace is directly with WP-CLI. This is an option for the WordPress developers out there.

Here is an example of what the command looks like:

wp search-replace 'http://example.dev' 'http://example.com' --precise --recurse-objects --all-tables