How to Fix Mixed Content Warnings After Switching to HTTPS

Overview

A mixed content warning means your page loads over HTTPS but still pulls some files (images, scripts, stylesheets, fonts) over plain HTTP. The fix is to change those http:// links to https:// at their source, which on WordPress usually means updating the site URL settings and running a search-and-replace on the database. Browser DevTools shows you exactly which files are at fault in under a minute.

In Chrome’s console the error looks like this:

Mixed Content: The page at 'https://yourdomain.com/' was loaded over HTTPS, but requested an insecure script 'http://yourdomain.com/wp-content/...'. This request has been blocked; the content must be served over HTTPS.

This guide is for site owners who have just installed an SSL certificate, or moved a site to a new host, and now see a broken padlock, a “not fully secure” notice, or parts of the page that stopped working. You’ll find every insecure URL, fix it at the source, and set things up so it doesn’t come back. If you haven’t got a working certificate yet, read what an SSL certificate is and why you need one first.

What causes mixed content

• Old URLs stored in the database. WordPress saves full URLs in posts, page builder data, widgets and theme settings. Installing SSL doesn’t change them.
• Hard-coded links in theme or plugin files, including CSS background-image rules and custom header or footer scripts.
• Third-party resources embedded over HTTP: an old analytics snippet, a widget, fonts or images from a site that doesn’t support HTTPS.
• Forms that post to an http:// address, which browsers flag with “The information you’re about to submit is not secure”.

Modern browsers treat these differently, which is why mixed content can be hard to spot. Plain images, audio and video are upgraded to HTTPS automatically, so they often look fine. Scripts, stylesheets, fonts and iframes are blocked outright. So are images in a srcset attribute, which WordPress uses for every responsive image. The usual result is a padlock that looks almost normal while a slider, menu, font or contact form quietly stops working.

How to fix mixed content warnings

Fix 1: Find every insecure URL

1. Open the page in Chrome, Edge or Firefox and press F12 (or Cmd+Option+I on a Mac).
2. Open the Console tab and reload the page. Every line starting with Mixed Content names the page and the insecure file.
3. Repeat on your main templates: the home page, a blog post, a product page, the cart and checkout, and any page with a form.

To check a page’s source from a terminal, this lists every HTTP resource the HTML references:

curl -s https://yourdomain.com/ | grep -oE '(src|href|srcset)="http://[^"]*"' | sort -u

Ignore ordinary <a href> links to other websites. Linking to an HTTP page is fine; loading a file from one is the problem.

Fix 2: Set WordPress to use HTTPS

1. In WordPress, go to Settings > General.
2. Change WordPress Address (URL) and Site Address (URL) from http:// to https://, and save. You’ll be logged out; log back in over HTTPS.

If those fields are greyed out, the URLs are set in wp-config.php as WP_HOME and WP_SITEURL. Edit them there with cPanel’s File Manager.

Fix 3: Replace old URLs in the database

This fixes most mixed content on WordPress sites in one pass.

Warning: A search-and-replace changes every matching row in the database and can’t be undone on its own. Take a full backup first, as described in how to back up your WordPress site.

With SSH access, WP-CLI does it safely, including serialised data that a plain SQL replace would corrupt. Run these from the site’s folder. The first command makes a backup, the second is a dry run that only reports what would change:

wp db export before-https.sql
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables-with-prefix --skip-columns=guid --dry-run

If the counts look right, run the same command without --dry-run, then repeat it with http://www.yourdomain.com if your site was ever reached on www. Finish with wp cache flush and clear any caching plugin.

Without SSH, a search-and-replace plugin such as Better Search Replace does the same job from the dashboard. Tick all tables, run it as a dry run first, and leave the GUID column alone.

Fix 4: Update hard-coded links in themes, CSS and page builders

Anything outside the database needs editing where it lives. To find those files over SSH:

grep -rln "http://yourdomain.com" wp-content/themes wp-content/plugins

• Theme files and custom CSS: change the URLs to https://, or to relative paths like /wp-content/uploads/logo.png. Edit a child theme rather than the parent so an update doesn’t undo it.
• Elementor: go to Elementor > Tools > Replace URL, then click Regenerate Files & Data on the same screen. Elementor keeps generated CSS files that the database replace doesn’t touch.
• Customizer and header/footer script plugins: check Appearance > Customize > Additional CSS, and any plugin you’ve used to paste tracking codes.

Fix 5: Replace third-party HTTP resources

For files hosted on someone else’s domain, try the same URL with https:// in a new tab. If it loads, update the link. If it doesn’t, the provider doesn’t support HTTPS: download the file and host it on your own site (if its licence allows), switch to a current version of the widget, or remove it. An analytics or chat snippet from several years ago is often the culprit, and the provider will have a current HTTPS version.

Fix 6: Add upgrade-insecure-requests as a safety net

While you track down the last few URLs, you can tell browsers to request everything over HTTPS by adding this to the top of the .htaccess file in your site’s root folder:

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

It only helps when the resource is actually available over HTTPS, and it hides the problem from the console rather than fixing it, so treat it as a stopgap. If your site already sends a Content-Security-Policy header (some security plugins do), add the directive to that policy instead of setting a second one. If the site shows a 500 error after the edit, remove the lines and see how to fix the 500 internal server error in WordPress.

How to prevent it

• Force HTTPS for the whole site. In cPanel, go to Domains and turn on Force HTTPS Redirect for the domain. It needs a valid certificate on the domain first. For Plesk, Nginx, IIS or a single-hop www rule, see how to redirect HTTP to HTTPS.
• Keep the certificate renewing. An expired certificate causes bigger warnings than mixed content. If AutoSSL fails, see SSL certificate not renewing.
• Use relative or HTTPS URLs in custom code, and paste media links from the Media Library rather than typing them.
• Run the search-and-replace as part of every move. Mixed content is common after a migration, when the old site was on HTTP. The steps in how to migrate WordPress to a new host include it.
• Re-check the console after installing a new theme, page builder template or tracking script.

On cPanel hosting, including Host & Tech cPanel shared hosting, open SSL/TLS Status before you turn on the redirect. It shows which of your domains and subdomains have a valid certificate, and lets you run AutoSSL for any that don’t.