How to Fix a Mixed Content Error on an HTTPS Website

You installed an SSL certificate, your site loads on HTTPS, yet the browser still shows a warning or a broken padlock, or some images are missing. The usual cause is mixed content: an HTTPS page that loads some files — images, scripts, stylesheets, fonts — over plain HTTP.

Why mixed content matters

• Security — HTTP files can be read or changed in transit, weakening the whole page.
• Broken pages — modern browsers block insecure scripts and stylesheets, and upgrade or block other files, so parts of the page can break.
• Trust — "Not secure" warnings scare visitors away, especially on checkout and contact pages.

How to find mixed content

1. Browser console — open the page, press F12, and check the Console for "Mixed Content" warnings that list each insecure URL.
2. Site audit — the free site audit report checks HTTPS and mixed content in its Security section.
3. Search your content — look for http:// links to your own domain in pages, posts, theme settings and widgets.

How to fix it

1. Update your own URLs — change http://yourdomain.com to https://yourdomain.com everywhere: content, menus, theme options, and the site address setting in your CMS. A careful search-and-replace on the database (after a backup) fixes old posts in bulk.
2. Fix third-party files — most services offer HTTPS versions. Replace the HTTP link; remove files from services that do not support HTTPS.
3. Host files yourself where possible, so you control the protocol.
4. Redirect HTTP to HTTPS for the whole site with a single 301 rule, and check it with the redirect checker.
5. Add a safety net — the upgrade-insecure-requests Content-Security-Policy directive tells browsers to load your page's HTTP resources over HTTPS. It helps, but fix the real links too.

Check images after the fix

Images are the most common mixed content. After updating links, confirm they load with the image URL checker and read how to fix broken images.

Where mixed content usually hides

• Old blog posts with images inserted before the site moved to HTTPS.
• Theme settings — logo, favicon and background image fields.
• Widgets and footers with hard-coded links.
• Embedded videos, maps and forms copied years ago with http:// addresses.
• CSS files that load fonts or background images over HTTP.

Check these places first; they account for most leftover warnings after an HTTPS move.

A worked example

A coaching institute moved to HTTPS but its homepage still showed "Not secure". The browser console listed three warnings: the logo set in theme options, a banner image in an old slider and a map embed. Updating those three addresses, then running a database search-and-replace for older posts, cleared every warning in under an hour.

Related guides

• Core Web Vitals Explained for Beginners: LCP, INP and CLS
• Duplicate Without User-Selected Canonical: What It Means and How to Fix It
• Noindex vs Disallow in Robots.txt: Which One Should You Use?

More free tools: browse all our free SEO tools, no sign-up needed.

Frequently asked questions