How to Fix Mixed Content Errors

What Is Mixed Content?

A mixed content warning shows up when a page loaded over HTTPS also pulls in a resource — a script, a stylesheet, an image, a font, or an iframe — over plain HTTP. The page itself is served securely, but something it depends on isn't, and the browser has to decide what to do about that gap before it renders the page.

Browsers treat two kinds of mixed content differently. Active mixed content — JavaScript, stylesheets, iframes, and similar resources that can change how a page behaves or looks — is blocked outright by every modern browser; if the HTTP version fails to load, the page simply runs without it, which usually breaks something visible. Passive mixed content, mainly images, audio, and video, is treated as lower risk since it can't rewrite the page, but current versions of Chrome still try to silently upgrade these requests to HTTPS first and only block them if the upgrade fails. Either way, an insecure content warning is the browser telling you that something on the page still points at http://. For a deeper technical breakdown of both categories, see MDN's mixed content documentation.

Why Mixed Content Breaks the Padlock and the Page

Once a browser blocks or flags mixed content, two things happen at once. The connection indicator in the address bar downgrades: instead of a plain padlock, visitors may see a warning icon, and the browser's own security panel will say the connection is only partially secure. That defeats the point of installing a certificate in the first place — the whole reason to move to HTTPS is to give visitors a private, verified connection; see our guide to what SSL/TLS actually does if you want the fundamentals first.

The second effect is functional, not just cosmetic. Blocked active content means blocked behavior: a stylesheet served over HTTP won't apply, so parts of the layout look unstyled; a script served over HTTP won't run, so a slider, a chat widget, or a checkout form can silently stop working with no visible error to a regular visitor — only to whoever opens the browser console. Mixed content itself doesn't directly change how HTTPS affects search rankings, but a page that looks broken or throws security warnings works against the same trust signals HTTPS was meant to protect.

How to Find Mixed Content Errors on Your Site

Before you can fix a mixed content warning, you need a full list of what's triggering it. Three methods cover most sites:

• Open the browser console. In Chrome, Firefox, or Edge, open developer tools (F12) and reload the page on the Console tab. Every blocked or upgraded request is logged individually, usually with the exact URL that was requested over HTTP, which is the quickest way to see what's actually happening on a page you already suspect.
• View page source. Search the rendered HTML for http:// — this catches image tags, hard-coded script and link tags, and inline embed codes that reference your own domain or a third party over plain HTTP, including ones that happen to load without triggering a console warning yet.
• Crawl the whole site. A single page rarely tells the whole story. Running a crawler (or a site-wide search-and-replace tool) across every template, post, and page surfaces old links, embedded media, and CDN references that were saved as http:// years before the site had a certificate at all.

Keep a simple list as you go — page URL, resource type, and whether it's your own asset or a third party's — since the fix differs for each of those cases.

Fix Hard-Coded HTTP URLs in the Database and Theme

Most mixed content on an established site comes from URLs that were saved as http:// before the site had a certificate, and never updated. On a database-driven CMS like WordPress, that usually means the site URL, image URLs, and embedded links are stored as absolute http:// addresses inside the database itself, not just in template files — so updating the theme alone won't fix it.

Back up your database and files first, then work through it in general terms: update the site's registered URL in its settings to the HTTPS version, then search the database for http://yourdomain.com and replace it with https://yourdomain.com — ideally with a tool built for the job rather than a raw find-and-replace, since serialized data (common in WordPress and similar platforms) breaks if a plain text replace changes the stored string length. Do the same pass over theme and plugin files for hard-coded http:// references in headers, footers, and widgets.

Once the obvious ones are fixed, re-crawl the site: a first pass on the database usually catches the majority of a mixed content warning, but embedded post content and custom fields often need a second look.

Fix Third-Party Embeds and CDN Assets

Not all mixed content comes from your own database. Embed codes for video players, maps, fonts, analytics tags, and ad scripts are often copied in years ago and never revisited; if the snippet hard-codes http://, it will trigger a warning regardless of how clean the rest of the site is. Go back to each third-party provider's current embed instructions and swap in the HTTPS version — almost every mainstream service has supported HTTPS for years, so this is usually a copy-paste fix.

The same applies to a CDN serving your own images, scripts, or stylesheets: check the CDN's configuration or asset URLs rather than assuming they inherited HTTPS automatically. Where you control the URL, prefer either a full https:// address or a relative path (/assets/style.css instead of http://yourdomain.com/assets/style.css) — a relative or protocol-matching URL can't become mixed content again if the domain is ever moved or aliased.

Use CSP upgrade-insecure-requests as a Safety Net

Once you've fixed what you can find, a Content Security Policy (CSP) directive called upgrade-insecure-requests acts as a safety net: it tells the browser to automatically rewrite any remaining http:// request on the page to https:// before sending it, rather than blocking it or leaving a warning. It won't fix a resource that genuinely doesn't exist over HTTPS, but it silently cleans up anything that does.

On an Nginx server, add it as a response header:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

Or, if you can't edit server configuration, add the equivalent HTML meta tag inside <head>:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Treat this as a backstop, not a substitute for the search-and-replace work above — it papers over remaining references instead of removing them, and it does nothing for a third-party resource that was never available over HTTPS in the first place.

Add HSTS Once Mixed Content Is Gone

HSTS (HTTP Strict Transport Security) tells the browser to only ever connect to your domain over HTTPS, even if a visitor types http:// or clicks an old link. It's a good final step, but only after mixed content is actually cleaned up — HSTS can prevent a visitor from clicking through a certificate warning, so turning it on while a chunk of your own site still references http:// assets removes the one workaround visitors had while you finish fixing it.

For the certificate and server-configuration side of getting HTTPS working properly — chain installation, HTTP-to-HTTPS redirects, and enabling HSTS — see our guide to installing an SSL certificate. And if you're seeing other browser security messages alongside mixed content warnings, our rundown of common SSL certificate errors covers what each one means.

Mixed Content Fix Checklist

Work through these in order the next time you see a mixed content warning:

• Open the browser console and note every blocked or upgraded request.
• Search the database and theme/template files for hard-coded http:// URLs and update them to https:// — back up first.
• Update third-party embed codes and CDN references to their HTTPS versions.
• Prefer relative or HTTPS URLs for anything you control going forward.
• Add upgrade-insecure-requests as a safety net for anything you missed.
• Re-crawl the site to confirm the console is clean.
• Only then enable HSTS.

Keeping Every Page Fully HTTPS

A mixed content warning almost always comes down to an old http:// reference somewhere — in the database, a theme file, or a third-party embed — rather than a problem with the certificate itself. Find every instance with the browser console and a full-site crawl, fix the database and theme first, update third-party embeds and CDN assets, use CSP's upgrade-insecure-requests as a safety net, and only add HSTS once the console is clean.

If part of the warning traces back to a subdomain or a newly added site that was never issued its own certificate, browse SSLCipher's SSL certificate options, starting with a straightforward DV SSL certificate for a domain that just needs to be covered.

Frequently asked questions