The WordPress mixed content error is what happens when a site running on HTTPS tries to load resources — images, scripts, stylesheets, fonts, iframes — over HTTP. Browsers treat this as a security problem. They either block the HTTP resources silently, downgrade the connection, or display a padlock with a warning indicator in the address bar. The padlock your visitors expect to see turns into a warning triangle, and Google Chrome’s developer console fills with messages like “Mixed Content: The page was loaded over HTTPS, but requested an insecure resource.” The WordPress mixed content error is extremely common after switching a WordPress site from HTTP to HTTPS — because the switch updates the site’s URL settings but does not automatically update every hardcoded HTTP reference scattered throughout the database, themes, and plugin settings. This guide covers every location where HTTP references hide, every tool for finding them, and every method for replacing them so the WordPress mixed content error clears completely. We go deeper on the whole subject in our WordPress Errors Complete Guide.
Understanding What the WordPress Mixed Content Error Actually Is
When a browser loads a page, it checks the protocol of every resource that page requests. On an HTTPS site, every request should use HTTPS. A WordPress mixed content error occurs when some requests use HTTP instead — mixing secure and insecure protocols on the same page. Browsers enforce different levels of restriction depending on the type of resource causing the WordPress mixed content error.
Browsers divide mixed content into two categories, and understanding the difference explains why some mixed content breaks functionality while other instances only trigger a visual warning:
| Type | Resources | Browser Action | Effect on Site |
|---|---|---|---|
| Active mixed content | Scripts (.js), stylesheets (.css), iframes, XMLHttpRequest | Blocked entirely by all modern browsers | Broken functionality, broken layouts, JavaScript errors |
| Passive mixed content | Images, audio, video | Loaded with a warning; may be blocked in future Chrome versions | Padlock warning icon; no broken functionality |
Active mixed content is the more urgent category. A WordPress mixed content error caused by a stylesheet or JavaScript file being loaded over HTTP means those files are blocked — the site may display without any styling, or JavaScript-dependent features (sliders, contact forms, checkout processes) fail entirely. The WordPress mixed content error from passive mixed content causes the padlock warning without breaking functionality, but it undermines trust and affects the perceived security of the site. Both types need to be resolved, with active mixed content treated as priority.
Finding Every Source of the WordPress Mixed Content Error
Before fixing the WordPress mixed content error, you need to know exactly which resources are loading over HTTP and where they are being referenced. The browser developer console is the starting point: press F12 in Chrome or Firefox, navigate to the Console tab, and load the page showing the mixed content warning. Every HTTP resource that triggers the WordPress mixed content error is listed there with its full URL and the location of the element that requested it.
For a systematic audit beyond what the console shows on a single page, the Why No Padlock tool (whynopadlock.com) scans a given URL and lists every HTTP resource causing the WordPress mixed content error — including resources in iframes that the browser console may not surface clearly. SSL Check tools from JitBit (jitbit.com/sslcheck) crawl an entire site and list all pages with mixed content issues, which is essential on larger sites where the WordPress mixed content error may appear on hundreds of individual URLs rather than just the homepage. Running both tools gives you a complete picture of the scope before starting fixes.
HTTP references that cause the WordPress mixed content error in WordPress typically live in one of four places: the WordPress database (in post content, widget settings, theme options, and plugin settings), active theme files (hardcoded URLs in templates, stylesheets, and functions.php), plugin settings and custom plugin files, and external resources that the theme or plugin loads from a third-party domain over HTTP. Each of these requires a different approach to fix, and a thorough audit usually turns up HTTP references in multiple locations simultaneously.
Fix the WordPress Site URL and Home URL Settings First
The root cause of most WordPress mixed content errors on newly HTTPS-migrated sites is that the WordPress Site URL and Home URL settings still reference http:// rather than https://. WordPress uses these values to construct URLs throughout the site — when they reference HTTP, everything WordPress generates from them triggers the WordPress mixed content error in the browser.
The cleanest fix for this specific cause of the WordPress mixed content error:
- Log in to the WordPress admin panel and go to Settings → General
- Update the WordPress Address (URL) field from
http://yoursite.comtohttps://yoursite.com - Update the Site Address (URL) field the same way
- Click Save Changes — WordPress redirects you to the login page after saving, which is expected
- Log in again and check whether the padlock warning has cleared on the site’s homepage
If the admin panel is not accessible because the WordPress mixed content error is severe enough to break the admin interface, update the URL settings via wp-config.php instead. Add these two lines before “That’s all, stop editing!”: define( 'WP_HOME', 'https://yoursite.com' ); and define( 'WP_SITEURL', 'https://yoursite.com' );. This overrides whatever is in the database and immediately forces HTTPS for site URL generation, resolving the most widespread source of the WordPress mixed content error without needing admin panel access.
Fix Hardcoded HTTP URLs in the Database
Changing the Site URL settings resolves future URL generation but does nothing for the thousands of HTTP URLs already stored in the database — in post content, image attachment URLs, widget text, option values, and serialised plugin data. Every one of these stored HTTP references is a potential source of the WordPress mixed content error after an HTTPS migration.
The Better Search Replace plugin (free; available from the WordPress plugin repository) is the safest tool for replacing HTTP URLs in the database. It handles serialised data correctly — a critical requirement, because a simple text find-and-replace on a WordPress database corrupts serialised PHP arrays that store plugin options, widget settings, and theme customiser values. Install Better Search Replace, go to Tools → Better Search Replace, enter your HTTP domain in the Search for field and your HTTPS domain in the Replace with field, select all database tables, and run a dry run first to see what will change before committing. Confirm the number of replacements looks sensible, then run the live replacement to clear the database-stored sources of the WordPress mixed content error.
WP-CLI is the alternative for users with command-line access: wp search-replace 'http://yoursite.com' 'https://yoursite.com' --skip-columns=guid. The --skip-columns=guid flag preserves the GUID values that WordPress uses for feed item identification — changing these causes duplicate items to appear in RSS feeds. The WP-CLI approach handles serialised data correctly by default and is faster than the plugin for large databases, making it the preferred method on VPS and managed hosting environments with SSH access. Both approaches eliminate the bulk of the database-level WordPress mixed content error sources in a single operation.
Fix Mixed Content Caused by Theme and Plugin Files
After the database search-and-replace, some WordPress mixed content error instances remain because the HTTP references are hardcoded in PHP files rather than stored in the database. Theme template files, functions.php, and plugin PHP files that contain hardcoded http:// URLs in wp_enqueue_style() or wp_enqueue_script() calls, image src attributes, or link href values need to be edited directly.
Use your text editor’s search function (or grep if you have server command-line access) to search the contents of your active theme’s directory and any custom plugins for the string http://. References to your own domain need to be changed to https:// or — better still — changed to protocol-relative URLs that start with // rather than specifying a protocol. Protocol-relative URLs load over whichever protocol the current page uses, making them immune to future WordPress mixed content errors if the site’s protocol changes again.
Third-party resources loaded by plugins and themes present a slightly different challenge for the WordPress mixed content error. Fonts from Google Fonts, scripts from CDNs, and images from external services all need to be loaded over HTTPS. Most major CDNs and font services support HTTPS natively — changing the URL from http://fonts.googleapis.com to https://fonts.googleapis.com is sufficient. For external resources that do not support HTTPS, the only option is to host them locally (download the resource and serve it from your own server) or replace them with an equivalent resource that does support HTTPS, since an external resource served over HTTP from a third-party domain will always produce the WordPress mixed content error regardless of what you do with your own server.
Force HTTPS Sitewide With .htaccess to Prevent Recurrence
Even after fixing every source of the WordPress mixed content error in the database, theme files, and plugin settings, new HTTP URLs can creep back in — from a plugin update that resets its settings to HTTP defaults, from a new piece of content where a contributor pastes in an HTTP image URL, or from an embedded external resource. Adding an HTTPS redirect in .htaccess ensures that any HTTP request to your site is automatically redirected to HTTPS at the server level, which prevents a different category of mixed content issue and provides a safety net against future WordPress mixed content error recurrences.
Add these lines to your .htaccess file, above the WordPress default rewrite rules:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
This redirects every HTTP request to its HTTPS equivalent permanently, which also contributes to SEO consolidation by ensuring only one version of each URL is canonical. The WordPress mixed content error caused by browser-initiated HTTP requests is prevented entirely when the server forces all connections to HTTPS before the page loads. The Really Simple SSL plugin (free; available from the WordPress plugin repository) automates this redirect and several other HTTPS migration tasks if you prefer a plugin-managed approach to the .htaccess configuration.
Our guide on how to add SSL to WordPress safely covers the full HTTPS migration process, including the DNS and certificate steps that precede the WordPress mixed content error fixes covered here — relevant if you are planning an HTTP to HTTPS migration rather than fixing a migration that was already done. Our guide on fixing the WordPress too many redirects error covers the redirect loop that sometimes appears after adding the HTTPS rewrite rule in .htaccess, which can happen when WordPress URL settings and server redirect rules conflict. The Google Web Dev documentation on mixed content covers the browser specification for active versus passive mixed content and which resources each browser version blocks — useful for prioritising which WordPress mixed content error sources to fix first when resources are limited. Related: How to Fix WordPress Image Upload HTTP Error.
