A "mixed content" or "partially secure" warning means the page itself loaded over HTTPS, but it's pulling in at least one resource — an image, script, stylesheet, or iframe — over plain HTTP. Browsers flag this because an attacker could tamper with that one insecure resource even on an otherwise secure page.
Finding the source
Open browser DevTools → Console. Mixed content warnings are logged individually with the exact URL of the offending resource, which is almost always faster than scanning your page source by eye.
Fixing it
- Change hardcoded
http://references in your theme, plugins, or database content tohttps://. - Use protocol-relative or root-relative URLs (
//yourdomain.com/file.js) where the platform supports it. - On WordPress specifically, a search-and-replace across the database is often needed since URLs get stored in post content, not just theme files.
Why active and passive content are treated differently
Modern browsers block active mixed content (scripts, iframes, stylesheets) outright by default, since a compromised script can inject arbitrary code into an otherwise secure page. Passive content like images is typically flagged with a warning rather than blocked, since a tampered image carries meaningfully lower risk. Understanding this distinction explains why some mixed content issues break page functionality entirely while others merely produce a visual warning.
Where mixed content most commonly hides
Beyond obvious page content, mixed content frequently hides in less visible places: a theme's compiled CSS file referencing background images via absolute http:// URLs, a third-party embed (an old social widget, an outdated analytics snippet) that was never updated to offer HTTPS, or a plugin's own separate settings screen storing a URL independently of your site's general content.
A Content Security Policy as both prevention and detection
Adding a CSP header with the upgrade-insecure-requests directive automatically upgrades any remaining http:// resource reference to https:// at the browser level, functioning as a safety net that also generates violation reports — useful both for immediately preventing the warning and for systematically discovering any remaining instances you haven't yet found manually.
Why a single-page application needs its own specific testing approach
Because a JavaScript-driven single-page application loads content dynamically rather than through a fresh page load per view, mixed content can be introduced only by a specific user interaction or route change — testing every route directly, not just the homepage, is necessary to catch every instance in this kind of application.