A mixed-content warning appears when an HTTPS page requests a resource over HTTP. The page itself may have a valid TLS certificate, but an insecure image, script, stylesheet, font, frame, or other resource can still be exposed to interception or modification. Browsers may upgrade some image, audio, and video requests automatically; other resource types are blocked. The exact console message tells you which URL and resource type to investigate.

Find the request in your browser

1. Open the affected page using its HTTPS address. Open the browser's developer tools and select the Console. Reload the page so current warnings appear.
2. Find the mixed-content warning and note the page URL, insecure resource URL, and whether the browser says it blocked or upgraded the request. Click the resource link when available to inspect its initiator and source location.
3. In the Network panel, reload with the log preserved if needed, then filter for the named resource. Check the request URL and status. A failed resource can have another cause too, such as a missing file or an HTTPS endpoint that does not serve that path.
4. Repeat on the affected page templates and key routes. A warning can come from page markup, a stylesheet, a script, a theme/plugin setting, a database field, or third-party content.

Do not infer that every insecure URL is harmless because it is an image. Browsers treat resource types differently, and an HTTP URL may be automatically upgraded or blocked depending on its type and context.

Fix the URL where it is generated

1. If the resource is on your site, change the stored or generated URL to an HTTPS URL after confirming that the exact hostname and path work over HTTPS. A root-relative path such as /images/header.jpg can avoid hard-coding the scheme for same-origin resources.
2. For a stylesheet or script, update the theme, plugin, template, or application setting that outputs the URL. For a CSS background or font, inspect the stylesheet named by the console or Network panel; the insecure URL may be nested in a CSS url(...) value.
3. For an external service, use its documented HTTPS endpoint if available. If it does not provide HTTPS, replace or remove that resource, or contact its maintainer. Do not change the scheme blindly: the server may not support HTTPS or may use a different path.
4. If the URL is stored in a content database, use the platform's supported search-and-replace or migration procedure, take a restorable backup first, and account for serialized data where relevant. Avoid a blind text replacement in database files.
5. Review downloads and embedded frames as well as visible images. A secure page should link to secure resources and downloads; a redirect or browser upgrade should not be treated as proof that the referenced endpoint is configured correctly.

Verify the repair

1. Reload the page with the Console open and confirm the specific warning is gone. Check that the resource now loads from HTTPS and returns the expected content.
2. Test the affected page in a current browser and inspect its main interactive elements. A blocked script or stylesheet can change behavior or layout even if the rest of the page appears.
3. Check other templates and routes that use the same theme, plugin, or content field. Clear only the relevant application or CDN cache if an old page response is still being served, then repeat the check.
4. Keep a note of the changed source and recheck after updates to themes, plugins, or embedded services that may reintroduce HTTP URLs.

A Content Security Policy directive such as upgrade-insecure-requests can request HTTPS upgrades, but it does not make an endpoint that lacks working HTTPS usable. Treat it as a policy tool, not a substitute for correcting and verifying resource URLs.

For related checks, see the TLS certificate date guide and DNS record format checker. A valid certificate and correct DNS records do not by themselves remove HTTP resource URLs from a page.

Source checked November 3, 2026

• MDN: Mixed content — describes mixed-content risks, browser upgrading and blocking behavior, console warnings, and repair and verification approaches.