Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
A WordPress page has a mixed content error when it loads over HTTPS but requests one or more resources—such as an image, stylesheet, or script—over HTTP. Fix it by confirming HTTPS works at the server, checking WordPress’s URL settings, finding the remaining HTTP requests in your browser console, correcting their source, and checking the affected pages again. Changing the site URLs alone may not fix references saved in content or generated by a theme, plugin, or external service.
What a mixed content error means
HTTPS protects a connection between a browser and a website. If an HTTPS page loads a resource over HTTP, that resource does not receive the same protection and could be observed or changed in transit. The page may still appear to load, but its security is weakened; an insecure script is particularly concerning because it can affect page behavior. See MDN’s explanation of mixed content.
Browsers may upgrade some requests, including many images, audio, and video files, while blocking other types, such as scripts and stylesheets. The result depends on the resource and its URL. An image appearing on the page does not prove that its source is secure, so use the browser console to diagnose the problem rather than relying on appearance.
Step 1: Confirm HTTPS works before changing WordPress
Open your site using its intended https:// address. HTTPS must be configured on the web server or on the proxy that handles encrypted connections before WordPress is told to use it. WordPress’s HTTPS guidance describes the certificate requirement.
If your site uses a reverse proxy, load balancer, or CDN that terminates TLS, check that WordPress receives the correct signal that the original visitor connection uses HTTPS. WordPress warns that forcing HTTPS administration without accounting for a proxy can cause redirect loops. Follow your host or proxy provider’s instructions for this setup; do not paste proxy configuration code without confirming it matches your environment.
Step 2: Check WordPress’s URL settings
In the dashboard, open Settings > General. Check that both WordPress Address (URL) and Site Address (URL) use the intended HTTPS hostname. The WordPress Address identifies where the WordPress core files are located; the Site Address is the URL visitors use to reach the site. They are often the same, but not always.
WordPress provides a function to update the home and siteurl options to HTTPS. It reverts the changes if WordPress does not detect HTTPS as active, which is why resolving the server or proxy configuration comes first. These settings affect URLs generated from those options; they do not guarantee that every older content link or theme, plugin, or external resource reference has been fixed.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →If a URL change makes the dashboard inaccessible, use your hosting provider’s recovery instructions. A database edit is not a universal fix: the correct recovery depends on how the site is hosted and configured.
Rank #3
Step 3: Find the HTTP requests in your browser
- Open an affected page in your browser.
- Open the browser’s developer tools and select the Console.
- Reload the page and note each mixed-content warning or error, including the full URL and resource type.
- Repeat on affected page types, such as posts, pages, forms, and pages using different templates. The home page may not load the same assets as the rest of the site.
The console can report resources that the browser upgrades as well as those it blocks. For each URL, trace where it originates: saved page or post content, a theme setting or stylesheet, plugin output, a hard-coded template, or an external service. That source determines where the durable fix belongs.
Step 4: Correct each source of an HTTP URL
For resources on your own site
Update the specific source that produces the HTTP address. Depending on what the console identifies, that may be a page or post, a theme setting, a stylesheet, a plugin setting, or a template reference. Correcting the source avoids depending on a browser workaround or runtime rewrite.
For resources hosted elsewhere
Check whether the provider offers the same resource over HTTPS. If it does, update the reference to the secure URL and verify that it loads. Simply changing http to https does not make a server support TLS. If the provider has no HTTPS endpoint, remove or replace the resource, or ask the provider about secure delivery. MDN recommends serving site content over HTTPS and using HTTPS URLs for resources wherever available.
Optional: Use a plugin as a diagnostic or temporary aid
The WordPress.org listing for SSL Insecure Content Fixer describes automatic basic fixes and advises checking the browser console for warnings. A plugin may help diagnose or temporarily rewrite requests, but it does not prove that stored references have been corrected or that HTTPS is properly configured. Treat the original URL source as the repair target.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Step 5: Verify the fix across your site
- If a caching layer is serving old markup, clear the relevant cache after correcting the source.
- Revisit each affected page type and reload it with the browser console open.
- Confirm that the mixed-content requests are gone and that referenced resources resolve over HTTPS.
- Check that page features still work, especially those that may rely on scripts, stylesheets, or forms.
A page can look normal even if the browser upgraded an image request or blocked a script. MDN also suggests testing with mixed content disabled or using a crawler or checker to find insecure references across a site; follow up on anything those checks identify.
Quick Recap
Troubleshoot what remains
- A redirect loop began after changing URL settings: Check whether a reverse proxy terminates TLS and whether WordPress receives the forwarded HTTPS indication. Use host-specific configuration guidance rather than forcing HTTPS administration blindly.
- Only some images or assets still warn: Use the exact console URL to locate the saved content, theme, plugin, or external service producing it. The two General settings do not necessarily change every individual reference.
- An external URL fails after changing it to HTTPS: The provider may not serve that resource over HTTPS. Restore a valid reference only if appropriate, then remove or replace the insecure resource unless the provider offers secure delivery.
- A plugin or browser upgrade makes the warning disappear: Verify the actual resource URLs and retest affected pages. A runtime rewrite or browser upgrade is not a substitute for correcting references and confirming resources load correctly.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
