Mixed Content Warning After Enabling HTTPS

What this error means & how to recognize it

• The page address uses HTTPS, but the browser’s developer tools report mixed content.
• A script, stylesheet, font, image, video, background image, or embedded frame fails to load or behaves differently after HTTPS is enabled.
• Console messages identify an HTTP resource requested by an HTTPS page.
• Page functionality is incomplete because active content, such as JavaScript or CSS, is blocked.
• The warning appears only on certain pages, templates, or user states, suggesting a hardcoded or conditionally generated reference.
• The site certificate appears valid for the main page even though individual resources still use insecure references.

Root causes, ordered by likelihood

1. Hardcoded HTTP references: Page content, templates, theme files, widgets, or stylesheets still point to a resource with an http:// address.
2. Old stored content: Images, embeds, media fields, scripts, or other database values retained HTTP references from before the HTTPS migration.
3. Theme or plugin output: A component generates an insecure URL even though the main site address is configured for HTTPS.
4. External resources without HTTPS support: A third-party script, font, frame, media file, or other dependency may not be available securely.
5. Cached or bundled files: Page caches, asset bundles, minified files, CDNs, or reverse proxies may still serve markup containing an older reference.
6. Outdated application or asset configuration: The application may build absolute URLs from an old base address or environment setting.

A mixed content warning does not, by itself, show that the site certificate is invalid. A certificate error concerns the secure connection to the site or resource host; mixed content concerns insecure resources requested within an otherwise secure page.

How to fix it

1. Confirm that the issue is mixed content

Open the affected page in a current browser and open its developer tools. In the Console, look for mixed content messages. In the Network panel, inspect the request identified in the warning and note its URL, resource type, status, and—when shown—the file or component that initiated it.

If the browser cannot establish a secure connection to the main site and displays a certificate warning, treat that as a separate problem. Do not change certificate settings to fix an insecure resource reference.

2. Identify all insecure references

Inspect the rendered page and, where appropriate, its source, stylesheets, scripts, and generated asset files for HTTP references. Check more than visible images: JavaScript, CSS, fonts, frames, media, and CSS background images can also cause warnings or loading failures.

Test the affected page in a private browsing window or after clearing the relevant browser cache. This helps distinguish a current insecure request from an old cached response, but it does not replace fixing the original reference.

3. Locate the source that generates the reference

Use the resource type and affected pages to narrow down where the URL originates:

• One article or page: inspect its stored content or media field.
• Several pages using one layout: inspect the shared template, theme, widget, or reusable component.
• Only pages using a feature: inspect the responsible plugin, integration, embed, or configuration setting.
• A request for a combined asset: inspect the source stylesheet, script, build process, cache, or proxy that produced the bundle.
• Different behavior for logged-in and logged-out visitors: compare the content and caching layers rendered for each state.

4. Update the reference at its source

Apply the fix that matches where the reference is stored:

• Change page or post content to use the HTTPS version of the resource.
• Update the site, media, theme, plugin, embed, or integration setting that generates the URL.
• Correct hardcoded references in templates, stylesheets, scripts, or configuration files.
• For a same-site resource, use a supported relative path when that fits the application and deployment structure.
• For an external resource, confirm that its host supports HTTPS. If it does not, replace the dependency with a secure source or remove it, especially when it provides active content.

5. Use bulk replacement only with safeguards

Bulk replacement is appropriate when the same outdated value is stored across many known records. Before changing production data, obtain authorization, create a restorable backup, define the exact scope, and test the operation on a staging copy or representative records when possible.

Account for serialized or structured data and avoid blindly replacing every occurrence of a text string. Review external hosts, redirects, file paths, configuration values, and records whose http:// text may not be a page URL. If the data structure is unfamiliar, ask the application owner or developer to perform the change.

6. Clear generated and cached content

After correcting the source, purge the application, page, CDN, reverse-proxy, and browser caches that may still contain old markup or asset bundles. Regenerate combined or minified assets if the site uses them. Only perform cache purges that are authorized for the affected environment, since they can temporarily increase origin traffic or change site behavior.

7. Verify the repair

Reload the affected pages and check the Console and Network panel again. Confirm that the previously flagged resource is requested securely, scripts and styles work, and no new insecure references appear.

Repeat the check across related templates and relevant logged-in and logged-out views. If the warning returns after a cache refresh, the underlying template, plugin, configuration, or generated asset still needs correction.

Prevention & how to verify the fix

• Add images, scripts, stylesheets, fonts, embeds, and media using HTTPS-aware references.
• Keep the application’s site address, asset settings, theme, plugins, and integrations consistent with HTTPS.
• Review third-party dependencies before deployment and replace providers that do not offer secure delivery.
• Include mixed-content checks in staging and post-migration testing.
• Inspect shared templates and reusable components, not only the page where the warning was first found.
• Maintain tested backups before bulk content changes and purge or regenerate affected caches and asset bundles afterward.
• Recheck pages with different authentication states when they render different resources.

Frequently asked questions