How to Fix the “Parse Error: Syntax Error Unexpected” In WordPress
February 18, 2026
Corporate Website Design Examples and WP Themes to Build Your Own
February 21, 2026Your SSL certificate is installed, but Chrome still says "Not Secure." That broken padlock usually means one thing: mixed content.
The WordPress mixed content error happens when your HTTPS pages load images, scripts, or stylesheets over plain HTTP. It's one of the most common issues after migrating a site to SSL, and it affects everything from visitor trust to search rankings.
This guide covers how to fix the WordPress mixed content error step by step. You'll learn how to find insecure URLs using browser DevTools, update your database with tools like Better Search Replace and WP-CLI, configure .htaccess redirects, and set up Content-Security-Policy headers to prevent the problem from coming back.
What Is the WordPress Mixed Content Error
The WordPress mixed content error shows up when a page loads over HTTPS but pulls in resources (images, scripts, stylesheets) using plain HTTP. Your browser catches this mismatch and flags the page as insecure.
That padlock icon in Chrome or Firefox? It disappears the second a single insecure resource loads. Visitors see a "Not Secure" label instead. And yeah, that's enough to make people bounce.
W3Techs data from January 2026 shows 87% of all websites now use a valid SSL certificate by default. That's up from just 18.5% back in 2016. The web has moved to HTTPS. Mixed content is what happens when parts of your site haven't caught up.
Active vs. Passive Mixed Content
Browsers treat insecure resources differently depending on what they are.
Active mixed content includes scripts, stylesheets, and iframes loaded over HTTP. These can change the behavior of the entire page, so browsers like Google Chrome block them outright. Your site breaks visibly.
Passive mixed content covers images, audio, and video files loaded over HTTP. Browsers often let these load but strip away the padlock icon. The page works, but the trust signal is gone.
Google's Transparency Report shows Chrome users spend 93.2% of their browsing time on HTTPS pages. That means your visitors already expect a secure connection. A missing padlock stands out.
How Browsers Display the Warning
Each browser handles it a bit differently, but the result is the same: your site looks untrustworthy.
- Chrome: Shows "Not secure" in the address bar and logs errors in the DevTools console
- Firefox: Displays a broken padlock icon with a warning triangle
- Safari: Removes the padlock and may block certain resources entirely
None of these warnings explain what's wrong to the average visitor. They just see something that looks unsafe and leave.
What Causes Mixed Content Warnings in WordPress
The error almost always traces back to a URL problem. Somewhere in your WordPress site, a resource is still loading with http:// instead of https://.
Took me a while to realize that enabling SSL doesn't automatically rewrite every URL stored in your database. WordPress saves full URLs, hardcoded with the protocol, every time you upload an image or add a link.
Common Sources of Insecure Content
Here's where the HTTP references tend to hide:
Database URLs: Old images, links, and media uploaded before your HTTPS migration. WordPress stores these as absolute paths in wpposts, wppostmeta, and wpoptions.
Theme files: Hardcoded HTTP links in header.php, footer.php, or custom CSS. Older themes especially tend to have these baked in.
Plugin output: Some plugins generate URLs with HTTP, particularly tracking scripts, font loaders, and widget embeds. Everything looks fine in the dashboard while the plugin silently causes warnings.
External resources: Third-party scripts, Google Fonts references from older implementations, embedded YouTube iframes, and CDN assets still pointing to HTTP endpoints.
WordPress powers roughly 43% of all websites globally according to W3Techs. With that many sites, a lot of them went through the HTTP-to-HTTPS transition at different points, carrying old URLs forward in the process.
How to Find Mixed Content on Your WordPress Site
The browser console is your best friend here. Open the page with the warning, right-click, select Inspect, and click the Console tab. Reload the page.
Chrome lists every insecure resource with its full file path. You'll see exactly which image, script, or stylesheet is loading over HTTP.
For a broader scan, tools like Why No Padlock and JitBit SSL Check crawl your pages and flag every insecure URL. They're free and take seconds to run.
| Tool | What It Does | Best For |
| Browser DevTools | Lists insecure resources on the current page via the "Security" tab. | Single-page diagnosis & real-time debugging. |
| Why No Padlock | Instant external scan of a specific URL for insecure scripts/images. | Quick, one-off checks for landing pages. |
| JitBit SSL Check | Crawls up to 400 pages for free to find internal HTTP references. | Small to medium site audits. |
| Screaming Frog | Comprehensive crawl with advanced "Security" filtering and AI-assisted analysis. | Large-scale enterprise sites and complex audits. |
| Cloudflare Dashboard | Identifies and automatically upgrades "Automatic HTTPS Rewrites." | Passive, server-side protection & automation. |
Start with DevTools for the page that's flagged. If multiple pages are affected, run a full site crawl.
How to Update WordPress URL Settings to HTTPS
This is the first thing to check. If your WordPress site URL settings still reference HTTP, everything downstream inherits that insecure protocol.
Go to Settings > General in your WordPress admin dashboard. Look at two fields: WordPress Address (URL) and Site Address (URL).
Both should start with https://. If they show http://, change them and save. That's it for this step.
What If You're Locked Out of the Dashboard
Sometimes the HTTP-to-HTTPS switch creates a redirect loop that blocks access to wp-admin. If that happens, you can force the URLs through wp-config.php.
Add these two lines above the "That's all, stop editing!" comment:
define('WPHOME', 'https://yourdomain.com'); define('WPSITEURL', 'https://yourdomain.com');
This overrides the database values and locks the URLs to HTTPS. Your mileage may vary depending on your hosting setup, but it works on most standard WordPress installations running on Apache or Nginx.
Before making any changes, confirm your SSL certificate is active and valid through your hosting panel (cPanel, Plesk, or whatever your host provides). Plenty of people skip this step and wonder why nothing works.
How to Force HTTPS with .htaccess or Server Configuration
Updating WordPress settings to HTTPS doesn't stop someone from accessing the HTTP version of your site. For that, you need a server-level redirect.
This forces all HTTP traffic to HTTPS automatically, which also helps clean up mixed content caused by internal links that still point to the old protocol.
Apache (.htaccess) Redirect
If your site runs on Apache (most shared hosting), add these lines to the top of your .htaccess file in the WordPress root directory:
RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.)$ https://%{HTTPHOST}%{REQUESTURI} [L,R=301]
This checks whether the connection is insecure and redirects it to the HTTPS version with a 301 permanent redirect.
Nginx Server Block
For Nginx, you'd add a separate server block that catches port 80 traffic:
server { listen 80; servername yourdomain.com www.yourdomain.com; return 301 https://$host$requesturi; }
Restart Nginx after making the change. Test it by typing your domain with http:// and confirming the redirect.
Sites Behind Load Balancers or Cloudflare
Here's where it gets tricky. If your site sits behind Cloudflare, AWS Elastic Load Balancer, or a similar reverse proxy, the standard .htaccess rules can create infinite redirect loops.
The server sees the connection from the proxy as HTTP even though the visitor's browser is using HTTPS. You'll need a different condition:
RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule ^(.)$ https://%{HTTPHOST}%{REQUESTURI} [L,R=301]
Cloudflare users should also check their SSL/TLS settings. "Flexible" SSL mode is a common culprit because Cloudflare connects to your origin server over HTTP. Switch it to "Full" or "Full (Strict)" to avoid mixed content issues between the CDN and your server.
How to Fix Mixed Content URLs in the WordPress Database
This is the big one. Most mixed content problems live in the database. Old posts, pages, custom fields, widget text, and theme settings all store full URLs with the protocol baked in.
You installed SSL, updated your site settings, added the redirect. But images in blog posts from two years ago? Still loading with http:// because that's what WordPress saved when you uploaded them.
Using Better Search Replace
The Better Search Replace plugin is the safest way to do a bulk URL update without touching SQL directly.
Install and activate it from the WordPress plugin directory. Go to Tools > Better Search Replace.
- In "Search for," enter http://yourdomain.com
- In "Replace with," enter https://yourdomain.com
- Select all database tables
- Run a dry run first to see how many replacements it finds
The plugin handles serialized data correctly, which matters a lot. WordPress stores some options and widget settings as serialized arrays. A raw SQL query can break serialization. Better Search Replace doesn't.
Back up your database before running the replacement. Always. Even with a dry run. I've seen sites break from search-and-replace operations that looked fine in the preview.
Which Database Tables to Target
You don't always need to hit every table. But if you want to be thorough (and you should), focus on these:
wpposts: Post content, page content, custom post types. This is where most insecure image URLs live.
wppostmeta: Custom fields, page builder data, ACF fields. Builders like Elementor and Beaver Builder store layout data here.
wpoptions: Site-wide settings, widget content, theme customizer values, and plugin configurations. A surprising amount of HTTP URLs end up here.
wptermmeta and wpcommentmeta: Less common, but still worth scanning if you've been running the site for years.
Using WP-CLI for Developers
If you're comfortable with the command line, WP-CLI's search-replace command is faster and doesn't require a plugin:
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run
Remove --dry-run when you're ready to commit. WP-CLI also handles serialized data properly, so it's a solid choice for developers managing multiple sites.
How to Use a Plugin to Fix Mixed Content in WordPress
Not everyone wants to edit databases or server configuration files. That's fair. Plugins exist specifically for this problem, and they work well for a quick fix.
Just know the trade-off: most of these plugins rewrite URLs on every page load instead of actually changing the stored data. They're a band-aid, not a permanent fix.
Really Simple SSL
Really Simple SSL detects your SSL certificate and automatically reconfigures WordPress to use HTTPS. It rewrites insecure URLs on the fly as pages render.
For most sites, it clears up mixed content warnings within minutes of activation. The plugin has evolved over the years though. It's no longer just an SSL fixer; it now includes broader security features, which some people find heavier than they need.
If your goal is purely fixing mixed content, it still does the job. But if performance matters to you (and it should for anything from SaaS websites to food websites), know that on-the-fly URL rewriting adds processing overhead to every page request.
SSL Insecure Content Fixer
This plugin offers more control. It has multiple fix levels, from "Simple" (which targets scripts, stylesheets, and media) to "Capture" (which rewrites everything including external resources).
The Simple level works for most WordPress sites. It catches the majority of insecure content without impacting performance much. Go to Settings > SSL Insecure Content after activation to configure it.
| Plugin | Approach | Best For |
| Really Simple Security | Full migration + real-time rewriting + vulnerability scanning. | Quick "one-click" setup for users who want a full security suite (formerly Really Simple SSL). |
| SSL Insecure Content Fixer | Tiered fix levels (Simple to Capture All) targeting specific resources. | Granular control; ideal for complex sites where some scripts break under aggressive rewriting. |
| Better Search Replace | Permanent, one-time database string replacement. | The "gold standard" for a clean, long-term fix without the overhead of a permanent plugin. |
Why Plugins Are a Temporary Fix
Plugins that rewrite URLs at runtime add overhead to every single page load. They intercept the HTML output, scan it for HTTP references, and replace them before the page reaches the visitor's browser.
For a small blog, the impact is minimal. For a site with hundreds of pages and heavy traffic, that's processing time you don't need to spend. The right move is to use a plugin for the immediate fix, then run a database search-and-replace to make the changes permanent, and finally deactivate the plugin.
A user friendly website shouldn't have to rely on workarounds that slow it down. Fix the source, then remove the crutch.
How to Fix Mixed Content from Themes and Plugins
Sometimes the database is clean and your settings are correct, but the browser console still flags insecure resources. That usually points to theme or plugin files that reference HTTP directly in their code.
This kind of mixed content doesn't show up in a database search because it's not stored in the database. It's hardcoded in PHP files, CSS, or JavaScript bundled with your theme or plugins.
Finding Hardcoded HTTP in Theme Files
Open your theme's directory via SFTP or the WordPress file manager. Search through header.php, footer.php, functions.php, and any custom CSS files for http:// references.
Look at how scripts and stylesheets are loaded. A properly built theme uses wpenqueuescript() and wpenqueuestyle() with protocol-relative or HTTPS URLs. Older themes sometimes hardcode full HTTP paths instead.
Quick fix: Replace http:// with https:// in the offending file. Better yet, use protocol-relative URLs like //yourdomain.com/style.css so the browser matches whatever protocol the page is using.
Plugin-Generated Insecure Content
SSL Pulse data from late 2024 shows roughly 30% of websites don't follow best practices for SSL implementation, often because of third-party code loading insecure assets.
Plugins that generate their own output (sliders, forms, analytics trackers, social widgets) can inject HTTP URLs into your pages without you realizing it. The fix depends on the plugin:
- Update the plugin. Many developers patched HTTP references years ago.
- Check the plugin's settings panel for URL fields still using HTTP.
- If neither works, contact the developer or switch to an alternative.
WP Engine's documentation recommends checking plugin and theme code via SFTP for any URLs hardcoded as HTTP in the files themselves. If you're building a professional website, relying on plugins with insecure output isn't a long-term option.
How to Fix Mixed Content from External Resources
External resources are trickier because you don't control them. These are scripts, fonts, embeds, and assets hosted on someone else's server.
Your database is clean. Your theme files are fine. But the browser console points to a third-party URL loading over HTTP.
Common External Sources of Mixed Content
Google Fonts (legacy references): Older WordPress themes loaded Google Fonts with http://fonts.googleapis.com. Google has supported HTTPS for years, so updating the URL fixes it.
Embedded iframes: YouTube, Google Maps, and other embed codes sometimes default to HTTP, especially if copied from older documentation or tutorials.
Third-party tracking scripts: Analytics tools, ad networks, and chat widgets occasionally serve assets over HTTP. This is less common today, but legacy integrations still surface.
What to Do When the External Source Doesn't Support HTTPS
It's rare, but it happens. Some older APIs, government data feeds, and niche services still don't offer HTTPS endpoints.
Your options:
- Host the resource locally on your own server (where you control the protocol)
- Remove the resource entirely if it's not critical
- Find an alternative service that serves over HTTPS
The APWG recorded 989,123 phishing incidents in Q4 2024 alone, many using free SSL certificates to appear legitimate. Browsers are getting stricter about mixed content for good reason. If an external resource can't serve over HTTPS, it's a liability regardless of mixed content.
For sites like technology websites or finance websites that handle sensitive data, removing insecure external dependencies should be a priority.
How to Verify Mixed Content Is Fully Resolved
Fixing one page doesn't mean the whole site is clean. Mixed content can hide on archive pages, category listings, old blog posts, and checkout flows that you haven't checked yet.
Browser-Level Verification
Go back to Chrome DevTools. Open the Console tab. Reload the page.
If the console is clear of mixed content warnings and the padlock icon shows in the address bar, that page is good. But you need to check more than the homepage.
Pages to test manually:
- Homepage
- A few blog posts (especially older ones)
- Archive and category pages
- Contact or form design pages
- Cart and checkout (if running WooCommerce)
Full Site Scanning
Manual checks only go so far. For a thorough audit, run a crawler.
| Tool | Type | Coverage | Best For |
| Screaming Frog | Desktop Crawler | Full site audit | Large-scale SEO audits; filters by protocol to find "Form on HTTP" errors. |
| JitBit SSL Check | Online Scanner | Up to 200–400 pages | Small to medium site audits with a clean, web-based report. |
| Why No Padlock | Online Scanner | Single URL | Instant "spot checks" for a specific page's scripts, images, and CSS. |
| Sitebulb | Desktop Crawler | Full site audit | Visual reporting; identifies issues where Chrome "Autoupgrades" resources. |
Screaming Frog is probably the most thorough option. Crawl your entire site, filter for HTTP URLs in images, scripts, CSS, and links. Anything still referencing http:// needs fixing.
The 2025 Web Almanac from HTTP Archive reports that over 98.8% of mobile requests now travel over HTTPS. If your site still triggers mixed content warnings after all the steps above, the problem is almost certainly a small number of leftover references. A full crawl will surface them.
Cross-Browser Testing
Chrome, Firefox, and Safari handle mixed content with slightly different levels of strictness. Chrome tends to be the most aggressive about blocking active mixed content, while Safari has its own quirks with passive content.
Test in at least two browsers. If the padlock appears consistently across both, you're in good shape.
How to Prevent Mixed Content Errors in WordPress Going Forward
Fixing the error once is good. Making sure it never comes back is better.
Most recurring mixed content problems happen because someone pastes an old HTTP link into a post, imports content from another site, or installs a plugin that doesn't use HTTPS properly. Prevention is about setting up guardrails.
Content-Security-Policy Headers
The upgrade-insecure-requests directive tells browsers to automatically load HTTP resources over HTTPS instead. Add it as a Content-Security-Policy header in your server configuration or through a security plugin.
The 2025 Web Almanac shows CSP adoption reached 21.9% of all websites, a 20% jump from the prior year. The upgrade-insecure-requests directive is one of the two most popular CSP directives, used on roughly 50-55% of sites that implement CSP.
For Apache, add this to your .htaccess:
Header always set Content-Security-Policy "upgrade-insecure-requests"
This won't fix URLs stored in your database, but it acts as a safety net. Browsers will attempt the HTTPS version of any HTTP resource before blocking it.
HSTS (HTTP Strict Transport Security)
What it does: HSTS tells browsers to always connect to your site over HTTPS, even if someone types http:// in the address bar or clicks an old HTTP link.
According to the 2024 Web Almanac, 60% of the top 1,000 websites have HSTS enabled. Among all sites, adoption sits around 31%.
Add the HSTS header to your server configuration:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
The max-age value of 31536000 equals one year. The includeSubDomains flag covers every subdomain. The preload flag lets you submit your domain to the HSTS preload list maintained by browsers.
Good Habits That Prevent Mixed Content
Headers handle the technical side. But day-to-day content management matters just as much.
When pasting URLs into posts: Always check the protocol. If you copy a link from an old email or document, it might use HTTP. Switch it to HTTPS before publishing.
When importing content: Run a search-and-replace for http:// immediately after any content migration. Don't wait for browser warnings to tell you something's wrong.
When installing plugins or themes: Check the developer's update history. Abandoned plugins that haven't been updated in two years are a common source of insecure resource loading. The WordPress plugin directory shows the "last updated" date. Use it.
Let's Encrypt now serves over 500 million websites and issues ten million certificates per day as of late 2025. SSL certificates are free and automated. There's no reason for any WordPress site to run without one, and no reason for any resource on your site to load over plain HTTP.
A well-maintained site with proper HTTPS configuration, clean database URLs, and current plugins shouldn't encounter the mixed content error again. But if it does, you now know exactly where to look and what to fix.
FAQ on How To Fix The WordPress Mixed Content Error
What is the WordPress mixed content error?
It occurs when an HTTPS page loads resources like images, scripts, or stylesheets over HTTP. Browsers flag the page as insecure, the padlock icon disappears, and visitors see a "Not Secure" warning in the address bar.
Why does mixed content appear after installing an SSL certificate?
Installing SSL doesn't rewrite existing URLs. WordPress stores full paths in the database. Old images and links uploaded before the HTTPS migration still reference http://, which triggers the mixed content warning in browsers.
How do I find mixed content on my WordPress site?
Open Google Chrome DevTools (F12), click the Console tab, and reload the page. Every insecure resource gets listed with its file path. Tools like Why No Padlock and JitBit SSL Check scan entire pages externally.
Can a plugin fix the mixed content error?
Yes. Really Simple SSL and SSL Insecure Content Fixer rewrite HTTP URLs on the fly. They work fast but add processing overhead to every page load. A permanent database fix is the better long-term approach.
How do I replace HTTP URLs in the WordPress database?
Use the Better Search Replace plugin or WP-CLI's search-replace command. Search for http://yourdomain.com and replace with https://yourdomain.com. Both tools handle serialized data safely. Always back up first.
What is the difference between active and passive mixed content?
Active mixed content includes scripts and stylesheets that browsers block outright. Passive mixed content covers images, audio, and video that browsers may still load but without showing the secure padlock icon.
Does mixed content affect SEO rankings?
Yes. Google uses HTTPS as a ranking signal. A site with mixed content warnings loses the secure connection indicator, which can reduce visitor trust and hurt click-through rates from search results.
How do I force HTTPS using .htaccess?
Add a RewriteRule in your .htaccess file that redirects all HTTP traffic to HTTPS with a 301 status. Sites behind Cloudflare or a load balancer need a modified rule using the X-Forwarded-Proto header instead.
What causes mixed content from themes and plugins?
Some themes hardcode HTTP URLs in PHP files or custom CSS. Plugins can generate insecure script references in their output. Updating both to the latest version usually resolves it, or you edit the files directly via SFTP.
How do I prevent mixed content from coming back?
Add a Content-Security-Policy header with the upgrade-insecure-requests directive. Enable HSTS to force HTTPS at the browser level. Check URLs before pasting them into posts, and avoid plugins that haven't been updated recently.
Conclusion
Knowing how to fix the WordPress mixed content error comes down to finding every http:// reference on your site and replacing it with https://`. The process is straightforward once you know where to look.
Start with your WordPress General Settings. Force HTTPS through your .htaccess or Nginx configuration. Run a database search-and-replace using Better Search Replace or WP-CLI. Then check your theme files and plugin output for anything still loading over an insecure connection.
After the cleanup, verify with Chrome DevTools and a full site crawl using Screaming Frog or Sitebulb.
Set up HSTS headers and a Content-Security-Policy with the upgrade-insecure-requests directive to keep the problem from returning. Monitor your SSL certificate expiration through your hosting panel or Let's Encrypt automation.
A clean HTTPS setup protects your visitors, keeps the padlock icon visible, and supports your search rankings going forward.
