Mixed content: your https site looks broken or has no padlock

Check the address first

If the page address in your browser starts with http:// rather than https://, the missing padlock is not caused by mixed content but by a missing redirect. See redirecting http to https. This guide is about sites that open over https:// but look or work wrong.

What mixed content is

A page opened over https:// is encrypted, but it can load other files: images, fonts, styles and scripts. If any of them has an address starting with http://, that is mixed content.

• Scripts, styles, fonts, frames and script requests over http:// are blocked by the browser. The page may then fall apart or stop working, e.g. the menu or a form.
• Images, audio and video over http:// the browser tries to load over https://, and blocks them if that is not possible. Images with versions for different screens (e.g. with the srcset attribute, which WordPress uses) and images with an IP address instead of a domain are blocked straight away.
• The icon next to the address usually does not change. A warning appears only when an insecure file does get loaded (e.g. after you allow insecure content in the site settings): in Chrome “Connection is not fully secure”, in Firefox a padlock with an exclamation mark or a crossed-out padlock.

How to find files loaded over http://

1. Open the page and press F12 (on a Mac, Cmd+Option+J in Chrome or Cmd+Option+K in Firefox). In the browser tools, go to the “Console” tab.
2. Reload the page. In Chrome and Edge the entries about problems start with “Mixed Content”, and in Firefox they contain the words “mixed active content”, “mixed display content” or “mixed (insecure)”. Each entry shows the full address of the file, starting with http://.
3. Check every subpage that looks or works wrong. Often the problem is in just one place, e.g. in the footer or the logo.

WordPress

Start only when https://example.com opens without a warning. Otherwise you may lose access to the dashboard. Also make a backup of the site and the database first (many hosting providers offer this in their panel).

The easiest way (WordPress 5.7 and newer): in the dashboard, choose “Tools” → “Site Health”. If you see “Your website does not use HTTPS”, click “Update your site to use HTTPS”. WordPress then changes the site address and replaces old http addresses in the content by itself whenever the content is displayed.

Manually:

1. Choose “Settings” → “General”. In the “WordPress Address (URL)” and “Site Address (URL)” fields change http:// to https:// and save. WordPress will ask you to log in again. If the fields are grayed out, the addresses are set in the wp-config.php file (WP_HOME and WP_SITEURL) and have to be changed there.
2. The old addresses remain in the content of posts and pages. Replace them with a plugin that searches and replaces in the database, e.g. Better Search Replace: in “Select tables” select all tables, enter http://example.com in “Search for” and https://example.com in “Replace with”. First do a trial run that saves nothing (the “Run as dry run” option). Replace the www variant too: http://www.example.com.
3. Check the settings of your theme and page builder (logo, background, fonts), because they sometimes store full addresses.
4. Clear the cache of your caching plugin (if you use one) and of your browser.

Other websites and online stores

• In the templates and files of your site, replace http://example.com with https://example.com or with relative addresses (starting with /).
• In the settings of your store or system (e.g. store address, base URL), enter the address with https://.
• Files from other services (maps, videos, fonts, widgets) must also have an address with https://. Almost every service has one; you just need to change the beginning of the address.

A quick fix on an Apache or LiteSpeed server

If you cannot fix the addresses right away, on an Apache or LiteSpeed server (which is what most shared hosting runs on) you can ask the browser to load the files over https:// by itself. Add this at the very top of the .htaccess file in your site's folder:

<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

This only works if the files are also available over https://. Treat it as a temporary solution and fix the addresses at the source. If your hosting does not have the headers module, these lines simply do nothing.

Checking

Reload the page bypassing the cache (Ctrl+F5, on a Mac Cmd+Shift+R). The page should look and work normally, and there should be no more mixed content entries in the console. Also make sure that everyone lands on the https version: we explain how on the page Redirecting http to https.