How to Fix Mixed Content (HTTP to HTTPS) in WordPress
You installed an SSL certificate, switched your site to HTTPS, and the padlock still won't show — or it shows on the homepage but breaks the moment you open a post. That's mixed content, and it's the single most common headache after moving a WordPress site to SSL.
The fix isn't a "force HTTPS" plugin. Those mask the symptom. The real fix is updating the old http:// URLs that are still sitting in your database, and this post walks you through doing that safely.
What "mixed content" actually is
Mixed content means a page served over HTTPS is loading some of its resources — images, scripts, stylesheets, fonts, iframes — over plain HTTP. The browser delivers the page securely, then sees an insecure http:// request inside it and refuses to call the whole page secure. So you get the broken padlock, a "Not fully secure" label, or a mixed content warning in the console.
There are two flavours:
- Passive mixed content — images, audio, video loaded over HTTP. The browser usually still loads them but downgrades the padlock.
- Active mixed content — scripts, stylesheets, iframes over HTTP. Browsers block these outright, which is why your layout or a slider sometimes breaks after going HTTPS.
Why the padlock breaks after you move to SSL
WordPress doesn't store relative paths everywhere. Over the years, your content accumulated hardcoded absolute URLs: an image inserted into a post is saved as http://yourdomain.com/wp-content/uploads/..., a page builder stores http:// asset URLs in its settings, a theme option points at an http:// logo.
Switching the certificate on the server does nothing to those strings. They were written into the database as http:// and they stay http:// until you change them. Some of them live inside serialized data (page builder layouts, widget settings, plugin options), which makes a naive find-and-replace risky — more on that below.
How to diagnose it
Before you change anything, find out what is loading over HTTP.
1. Browser console. Open the broken page, press F12, and look at the Console tab. Mixed content warnings name the exact offending URL — for example:
Mixed Content: The page at 'https://yourdomain.com/post' was loaded over HTTPS, but requested an insecure element 'http://yourdomain.com/wp-content/uploads/logo.png'.
That tells you it's your own uploads, not a third-party script.
2. Padlock details. Click the padlock (or the "Not secure" text) in the address bar. Chrome and Firefox both show whether the connection is fully secure and why it isn't.
3. "Why No Padlock" or similar checkers. Paste your URL into a tool like Why No Padlock and it crawls the page for insecure elements and lists them. Useful when the console is noisy.
Once you can see that the problem is your own http://yourdomain.com URLs, the cause is clear: they're in the database, and they need to be rewritten.
The real fix: a site-wide search & replace
Here's the honest part. A "force HTTPS" or SSL plugin rewrites those http:// URLs on the fly, on every page load, using output buffering. It works, but:
- It runs on every request, adding overhead.
- It only fixes the front end — your stored data is still wrong.
- Deactivate the plugin and the mixed content comes straight back.
- It does nothing for URLs that live in serialized data the buffer doesn't reach.
The permanent fix is to change the URLs at the source — in the database — replacing every http://yourdomain.com with https://yourdomain.com. Do that once and the mixed content is gone whether or not any plugin is active.
The catch is that a raw SQL REPLACE can corrupt serialized data, and you want a way back if something looks wrong. That's exactly what Update URLs is for: a serialization-aware search & replace with a dry run, a table picker, and a one-click undo. For the full background on doing this safely, see the pillar guide: WordPress Search and Replace: A Safe Guide.
Step-by-step: fix mixed content with Update URLs
1. Back up the database first
Never run a site-wide replace without a backup. Update URLs has a built-in one-click DB backup — take it before you touch anything. If a replace goes sideways, this is your fastest route back, alongside the Undo feature below.
2. Enter the search and replace values
Set up the replacement exactly:
- Search for:
http://yourdomain.com - Replace with:
https://yourdomain.com
Use your real domain, and include the http:// and https:// so you only flip the protocol — not other text. Replacing the full URL prefix (rather than just http) avoids accidentally mangling unrelated strings. The mechanics are covered in How to do search and replace text in WordPress.
3. Pick the right tables
You don't need to touch every table. For mixed content, the URLs almost always live in:
wp_posts— image and asset URLs embedded in post and page content.wp_postmeta— page builder layouts, custom fields, attachment metadata.wp_options— theme options, widget settings, plugin config.
Use the table picker to select these rather than blasting the whole database — it's faster and lower-risk. If you're unsure which tables hold your builder's data, the guidance in How to run search and replace on selected tables helps you narrow it down.
4. Run a dry run first
This is the step people skip and regret. A dry run scans the selected tables and reports exactly how many rows would change and where — without writing anything. You get to review the impact before committing.
If the count looks wildly off (zero matches, or tens of thousands you didn't expect), stop and check your search string. Walkthrough: How to do a dry run before search and replace.
5. Apply the replacement
Happy with the dry-run preview? Apply it. Update URLs lets you selectively apply the change, and because it's serialization-aware it rewrites URLs inside serialized arrays without breaking the string-length counts that PHP relies on.
6. Undo if anything looks wrong
If the front end looks off after applying, you don't have to scramble for your backup. Update URLs keeps a one-click Undo / Rollback of the operation — something a raw SQL REPLACE or the classic Better Search Replace flow can't offer. Roll it back, fix your inputs, and try again. Every run is recorded in history/profiles so you can see what changed and reuse the same settings later.
Handle serialized data safely
Page builders (Elementor, Divi, WPBakery), sliders, and many plugins store their settings as serialized PHP arrays. Serialized strings embed the byte length of each value, so a blind http:// → https:// swap changes the text but not the recorded length, and the array silently breaks — your layout vanishes or the builder throws errors.
Update URLs unserializes, replaces, and re-serializes correctly so the lengths stay valid. You don't have to do anything special, but it's worth understanding why this matters: How to update serialized data effectively. If your images specifically are the problem, there's a focused walkthrough too: Bulk replace image & attachment URLs in WordPress.
For a deeper look at why serialized replacements go wrong with naive tools, see WordPress search & replace on serialized data, safely.
When to also update siteurl and home
Separate from content URLs, WordPress stores two core settings — siteurl (WordPress Address) and home (Site Address) — in the wp_options table. If these still read http://, WordPress itself generates insecure links and can fight your HTTPS setup.
Check Settings → General. If both fields already show https://, you're done — the search & replace above handles the rest. If they're greyed out or still http://, update them (via the settings screen, or as part of your wp_options replace). Note: changing siteurl/home is also the core of a full domain migration — if you're moving hosts or domains at the same time, follow Move WordPress to a new domain so you update everything in one pass.
Verify the padlock
After the replace:
- Hard-refresh the previously broken pages (Cmd/Ctrl + Shift + R) to clear cached HTTP assets.
- Clear any caching plugin / CDN cache — stale cached HTML can still serve old
http://markup. - Re-open the console on the pages that failed before. No mixed content warnings means you're clean.
- Confirm the padlock appears site-wide, including posts, the cart/checkout, and any page builder pages.
If one stubborn warning remains and it points at a third-party domain (an external script or font loaded over HTTP), that's the provider's URL — update that specific reference, since your own database is now clean. If you're still stuck, the Update URLs troubleshooting guide covers the common edge cases.
Conclusion
Mixed content after moving to HTTPS isn't a certificate problem — it's old http:// URLs frozen into your database. Force-HTTPS plugins paper over them on every page load; a proper search & replace removes them for good. Back up, replace http://yourdomain.com with https://yourdomain.com, dry-run it, target wp_posts, wp_postmeta, and wp_options, apply, and keep the one-click Undo in your back pocket. Do it once, verify the padlock, and you never think about it again.
FAQs
Why is my padlock still broken after switching to HTTPS?
Almost always because your content and settings still contain hardcoded http://yourdomain.com URLs for images, scripts, or styles. The certificate secures the connection, but the browser sees those insecure requests and downgrades the padlock. A site-wide search & replace from http:// to https:// fixes it at the source.
Do "force HTTPS" plugins fix mixed content permanently?
No — they rewrite URLs on the fly on every page load, which adds overhead and only fixes the front end. Your stored data stays wrong, and the moment you deactivate the plugin the mixed content returns. Updating the URLs in the database is the permanent fix.
What about serialized data — won't a replace break my page builder?
It will with a naive SQL REPLACE, because serialized PHP strings store byte lengths that a blind swap leaves invalid. Update URLs is serialization-aware: it unserializes, replaces, and re-serializes so lengths stay correct and your builder layouts survive. See How to update serialized data effectively.
Will fixing mixed content affect my SEO?
Positively, if anything. Moving fully to HTTPS is a ranking signal, and resolving mixed content means browsers serve your pages as secure, which helps trust and conversions. As long as you keep the same domain and your siteurl/home are on https://, there's no negative SEO impact.
Can I undo the replacement if something goes wrong?
Yes. Update URLs records every operation and offers a one-click Undo / Rollback, plus a built-in one-click database backup you take beforehand. Between the two, you can always get back to the pre-replace state — which is why running the dry run and then applying is low-risk.