If Chrome is blocking parts of your page, mixed content is usually the reason.
This guide explains how to fix Chrome mixed content warning issues by identifying insecure resources, updating site references, and preventing the problem from returning.
What Chrome mixed content warning means
A mixed content warning appears when a page loads over HTTPS but requests one or more resources over HTTP.
Chrome treats the secure page as trustworthy, but the insecure subresource can weaken that trust and expose users to risk.
Typical mixed content resources include:
- Images served over HTTP
- Stylesheets loaded from insecure URLs
- JavaScript files referenced with http://
- Fonts, videos, or iframes embedded from insecure sources
Chrome distinguishes between passive mixed content and active mixed content.
Passive content such as images may display with warnings, while active content such as scripts and iframes is more likely to be blocked entirely because it can alter page behavior or expose user data.
Why mixed content happens
Mixed content usually appears after a site migration from HTTP to HTTPS, a CMS update, or a change in theme, plugin, or third-party embed.
It can also happen when database content still contains old URLs or when a CDN or proxy serves outdated links.
Common causes include:
- Hardcoded http:// links in page templates or posts
- Legacy media URLs stored in the WordPress database
- Third-party widgets that have not been updated for HTTPS
- External scripts or APIs that still use insecure endpoints
- Improper redirects during an HTTP to HTTPS migration
How to identify mixed content on your page
Before you can fix Chrome mixed content warning errors, you need to find the exact resources causing them.
Chrome DevTools makes this straightforward.
Use Chrome DevTools
Open the page, right-click, and choose Inspect.
In the Console tab, look for mixed content messages.
Chrome usually lists the blocked or upgraded resource and its exact URL.
You can also check the Network tab and filter by HTTP requests.
This helps reveal images, scripts, or styles that are still loaded insecurely.
Check the page source
View the HTML source and search for http://.
Look for links in image tags, stylesheet references, script tags, iframe embeds, and inline CSS.
This method is useful when the warning is caused by hardcoded URLs in templates or content blocks.
Scan the database and media library
In CMS platforms like WordPress, mixed content often lives in stored content rather than theme files.
Posts, pages, widgets, menus, and custom fields may still contain old HTTP links.
Media library URLs can also retain the original protocol if the site was migrated.
How to fix Chrome mixed content warning in WordPress
If your site runs on WordPress, the fastest fix is often to replace insecure URLs sitewide and ensure the platform generates HTTPS links by default.
1. Update the site URL settings
In WordPress, go to Settings and verify that both the WordPress Address and Site Address use https://.
If either field still uses HTTP, internal links may continue to load insecurely.
2. Replace old HTTP links in the database
Use a reliable search and replace tool or a plugin such as Better Search Replace to swap http://yourdomain.com with https://yourdomain.com.
This helps fix content, widgets, and custom fields without manual editing.
Be careful to use a tool that supports serialized data, since WordPress stores some values in formats that can break if edited incorrectly.
3. Update theme and plugin files
Review theme templates, custom JavaScript, and plugin settings for hardcoded URLs.
Replace insecure references with protocol-relative or HTTPS URLs where appropriate.
If a plugin is outdated and still calls HTTP assets, update it or find an alternative that supports secure delivery.
4. Regenerate embedded media links
If images are still loading over HTTP, resave them through the media library or reinsert them into posts so WordPress generates the current HTTPS path.
For large sites, a database update is usually more efficient than editing each image manually.
5. Fix mixed content in page builders
Elementor, Divi, WPBakery, and similar builders often store absolute URLs inside layout data.
Open the page in the builder, inspect images and background sections, and update each asset to use HTTPS.
Some builders also include a sitewide replace utility.
How to fix mixed content on other platforms
Mixed content is not limited to WordPress.
Any CMS, static site, or custom application can load insecure resources if URLs were not updated during deployment.
- Shopify: Check theme files, custom liquid sections, and app embeds for HTTP references.
- Joomla and Drupal: Review template files, modules, and stored content for insecure asset links.
- Custom sites: Search code repositories, environment variables, and frontend bundles for http:// endpoints.
In each case, the goal is the same: every resource loaded by the page should be available over HTTPS.
Can you use Content Security Policy or auto-upgrade?
Chrome and modern browsers support mechanisms that can reduce mixed content issues, but they should complement, not replace, a proper fix.
Upgrade-Insecure-Requests
The upgrade-insecure-requests Content Security Policy directive tells browsers to try upgrading HTTP requests to HTTPS automatically.
This can help with legacy links, but only if the destination server supports HTTPS.
Content-Security-Policy headers
A well-configured Content Security Policy can help control what resources the browser is allowed to load.
It can reduce future insecure requests, especially when paired with strong deployment practices.
HSTS
HTTP Strict Transport Security forces browsers to use HTTPS after the first secure visit.
HSTS helps prevent accidental HTTP access, but it does not fix broken links embedded in your content.
You still need to update the source URLs.
How to prevent mixed content from coming back
Once you fix Chrome mixed content warning issues, prevention matters just as much as cleanup.
The most effective approach is to make HTTPS the default in every layer of your stack.
- Use HTTPS-only URLs in templates and content
- Set up automatic HTTP to HTTPS redirects
- Audit third-party scripts before installing them
- Use a deployment checklist after migrations or redesigns
- Monitor Chrome DevTools or security scanners for new warnings
It also helps to standardize asset delivery through a trusted CDN such as Cloudflare or Fastly, configured to serve all files over HTTPS.
If your team publishes content regularly, create editing guidelines so authors do not paste old HTTP links into posts or widgets.
What to do if the warning persists after fixing URLs
If Chrome still shows mixed content after you have updated links, the issue may be hidden in a cache layer, service worker, or redirect chain.
Clear browser cache, purge your CDN cache, and refresh any server-side caches before retesting.
Also check for:
- Old versioned assets still referenced in CSS or JavaScript bundles
- Redirects that send HTTPS requests back to HTTP
- API responses that return insecure asset URLs
- Browser extensions that inject insecure content
If the warning appears only on a specific page, compare its HTML output with a working page.
That often reveals the exact widget, embed, or template fragment responsible for the issue.
When mixed content is a security and SEO problem
Mixed content is more than a browser annoyance.
It can undermine user trust, break page functionality, and interfere with secure features like geolocation, service workers, and payment workflows.
Search engines also prefer technically sound HTTPS pages, especially when site quality signals are compared across competing pages.
For ecommerce, membership, and login pages, fixing mixed content is especially important because insecure requests can affect form security and conversion rates.
For publishers, it can damage usability if key scripts or layout styles fail to load.
By identifying insecure resources, replacing them at the source, and enforcing HTTPS across your stack, you can eliminate mixed content warnings and keep Chrome from blocking critical page elements.