Quick answer
Mixed content occurs when an HTTPS page requests an insecure HTTP resource. Find the exact request in browser developer tools and correct its source URL to a working HTTPS endpoint or suitable relative path. First resolve any certificate warning on the main page itself.
Confirm the page itself has valid HTTPS
Check that the main page loads through valid HTTPS. A mixed-content warning concerns an insecure resource inside that secure page, not a certificate problem on the page itself. Old URLs can remain in templates, CSS, content or the database.
Browsers may upgrade some image, audio and video requests to HTTPS, while blocking scripts, stylesheets and other insecure requests. A missing picture is not proof that every image type was blocked; inspect the exact request and browser message.
Find the failing request and its owner
Open developer tools on the affected page, reload and read the console and network entries. Record the page URL, insecure resource URL, request type, resulting status and whether the browser upgraded or blocked it. Check representative landing pages, deep pages, forms and mobile templates because a single clean homepage can miss embedded content. Separate first-party URLs you control from third-party widgets or assets supplied by another vendor.
Inspect the application template or content field that emitted the URL. A response blocked by mixed-content policy will often have no successful network fetch; a resource upgraded to HTTPS may still fail if the target has no valid HTTPS endpoint.
Make a targeted application change
For a first-party resource, use a correct HTTPS URL or a suitable relative path after confirming it is served at the target hostname. For an external resource, use the supplier’s HTTPS endpoint or replace the dependency; do not proxy an unknown insecure script merely to silence the warning. Test one template or content field before applying the same scoped fix elsewhere. Avoid a blind database-wide search-and-replace: serialized data, external links and intentional non-web values can be damaged.
Do not weaken browser security or turn off HTTPS to make a broken asset appear. Certificate installation and origin configuration belong to their own service workflow.
Verify the fix and retain recovery
Reload with a fresh browser session and check that the intended resource succeeds over HTTPS. Confirm layout, interaction, downloads and forms still work, then test a second browser or device. Retain the before-and-after URLs and the small content or code change. If the fix breaks rendering or an integration, restore that scoped change and investigate the original resource owner and path.
Example: a stylesheet still uses HTTP
If https://www.example.com/ includes http://www.example.com/theme.css, change the template to the confirmed HTTPS URL or an appropriate relative path. An HTTP-to-HTTPS server redirect may not help because the browser can block the stylesheet before fetching it.
After editing, confirm the actual resource request succeeds over HTTPS and the page still behaves correctly. If only one template is fixed, repeat the check on another page using a different template before declaring the site clear.
Frequently asked questions
Why does an image appear despite an HTTP URL? Many browsers attempt an automatic HTTPS upgrade for certain media. Correct the source reference anyway and test that the upgraded URL works.
Will a redirect from HTTP to HTTPS fix an insecure script? The browser may block the request before following a redirect. Point the application directly to a valid HTTPS resource.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.