Fix mixed content and HTTPS errors: a step-by-step guide

You have set up HTTPS, but your browser still does not show a fully secure connection, or you keep seeing a warning about insecure elements. Usually the cause is mixed content: a secure HTTPS page that quietly still loads some files over plain HTTP. This guide explains what mixed content is, why browsers block it, and gives you a step by step plan to fix mixed content and HTTPS errors, whether you run WordPress or a static site.

What is mixed content?

Mixed content happens when a page is loaded over HTTPS, but individual elements on that page are still fetched over insecure HTTP. Think of images, scripts, stylesheets, fonts, videos or iframes. The main page is encrypted, but those elements are not. As a result the page is no longer fully secure, which is exactly what the browser wants to prevent.

An element that arrives over HTTP can be read or altered along the way by someone who intercepts the network traffic, a so-called man-in-the-middle. With a script or stylesheet this is especially risky, because it lets an attacker run code on your page or change its content. The promise of HTTPS, that no one can eavesdrop or tamper, then no longer holds for the whole page.

To use HTTPS you need a valid SSL certificate. At LJPc hosting you get one for free through Let's Encrypt, requested and renewed automatically once your domain points to the server. A certificate alone does not fix mixed content, though, because the insecure references sit inside your own site content.

Active and passive mixed content

Browsers split mixed content into two types and treat them differently. The type decides whether an element is upgraded automatically or blocked straight away.

Passive (upgradable) mixed content

These are elements that only display something and do not drive the rest of the page: images through the img element, background images in CSS, and audio or video through the audio, video and source elements. Modern browsers try to upgrade these requests to HTTPS automatically. If that fails, the element is blocked. There is no fallback to HTTP.

Active (blockable) mixed content

These are elements that can affect the whole page: scripts, stylesheets loaded through link, iframes, fonts, and requests through fetch or XMLHttpRequest. Images with a srcset and sources inside a picture element also count here. The browser blocks these straight away, because the risk is too high. The result is often a broken layout, missing features or a page that looks different from what you intended.

Spotting mixed content in the browser

The padlock in the address bar is a less reliable clue than it used to be. What you actually see differs per browser and per version.

• In Chrome the familiar padlock was replaced in version 117 (September 2023) by a neutral settings icon with two sliders. That icon says nothing about mixed content by itself.
• The "Not secure" label mainly appears for pages that load entirely over HTTP, not always for a single insecure element on an otherwise secure page.
• Firefox, Safari and Edge each show their own variant, and the details change with almost every update.

If you want to know for certain whether there is mixed content, use your browser's developer console (DevTools). It is far more reliable than the icon in the address bar.

Finding the cause with DevTools

Your browser's console points you straight to the insecure element:

1. Open the page and press F12, or right click and choose "Inspect".
2. Go to the Console tab.
3. Reload the page so every element is loaded again.
4. Look for lines that start with "Mixed Content".

The browser names the insecure URL for each element, for example: Mixed Content: The page at 'https://yoursite.com/' was loaded over HTTPS, but requested an insecure resource 'http://...'. This request has been blocked. That tells you exactly which file is still loaded over HTTP. The Network tab lets you filter requests as well, so you can see which resources come in over http://.

Fix mixed content and HTTPS errors in WordPress

Most mixed content in WordPress comes from URLs that are hard coded somewhere with http://. Work through it methodically:

1. Check your site URL. Go to Settings > General and set both "WordPress Address (URL)" and "Site Address (URL)" to https://.
2. Replace old URLs in the database. Many http:// links live in posts, pages and widgets. With WP-CLI you can replace them in one go: wp search-replace 'http://yoursite.com' 'https://yoursite.com'. WP-CLI handles serialised data correctly. Back up your database first.
3. Check hard coded references. Look in your theme, in custom HTML widgets and in menus for images, scripts or iframes that still use http:// and update them.
4. Save your permalinks again. Go to Settings > Permalinks and click Save Changes to refresh the references.

If you would rather not fix every reference by hand, you can let the browser upgrade all insecure requests automatically with a security header. That is described further down.

Fix mixed content on static sites

On a static site or loose HTML files you edit the source directly. Search your HTML and CSS for http:// and replace those references with https://. Pay particular attention to embedded content such as video embeds, maps, fonts and external scripts, because mixed content often hides there. If an external resource only works over HTTP, find a version that supports HTTPS or host the file on your own site.

Forcing HTTPS with .htaccess

If visitors can still open your site over http://, it is best to redirect them to the HTTPS version automatically. Make sure your SSL certificate is active first, otherwise you send visitors to a page that will not load. On an Apache server you set up the redirect with a few lines in the .htaccess file in your site's root folder:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

If your site sits behind a load balancer or proxy, use this variant, which checks the forwarded header:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Note: a redirect only sends the main page to HTTPS. The insecure references to images, scripts or stylesheets inside that page remain. You still fix those in the content itself, or let them upgrade with the header below.

Upgrade everything at once with a security header

If you have many separate references, the header Content-Security-Policy: upgrade-insecure-requests is a handy safety net. It tells the browser to fetch every http:// request on your page as https:// automatically. You set it as an HTTP header or as a meta tag in the head of your page:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

This is a safety net, not a replacement for cleaning up your URLs: the resource does need to be reachable over HTTPS. You can read more about headers like this in the article on setting HTTP security headers.

With these steps you usually fix mixed content and HTTPS errors quickly: recognise the problem in the console, track down the http:// references and update them in your CMS or files. Still stuck? Get in touch with our support team and we will take a look with you.