Mixed content errors on HTTPS: find and fix every http:// resource
Browsers block http:// scripts, styles, iframes and fetch calls on HTTPS pages and upgrade images and media. How to find every insecure URL and fix it.
LLaunchScaler·Published ·8 min read
A mixed content error means a page loaded over https:// asked for a resource over http://, and the browser either blocked it or rewrote it. Scripts, stylesheets, iframes, fonts and fetch or XHR calls are blocked outright, which is what breaks layouts, forms and checkouts; images, audio and video set with src are upgraded to https:// automatically and only log a warning.
The fix is always the same: change the URL at its source to https:// or a relative path. The hard part is finding where the URL lives, so most of this guide is about that.
What is blocked and what is upgraded?
MDN's mixed content guide divides requests into two groups. Upgradable content is rewritten from http to https and requested again; blockable content is never requested at all. Anything not on the upgradable list is blockable, and new resource types default to blocked.
Resource on an HTTPS page
What the browser does
What you see
<script src="http://...">
Blocks it
Broken features, console error
Questions, answered
What people ask about this
01
What is a mixed content error?
It is the browser refusing, or rewriting, an http:// resource requested by a page loaded over https://. Scripts, stylesheets, iframes, fonts and fetch calls are blocked outright; images, audio and video set with src are upgraded to https:// automatically.
fetch(), XMLHttpRequest, navigator.sendBeacon() to http://
Blocks it
Failed API calls, missing data, lost analytics
Web fonts and @font-face URLs
Blocks them
Fallback font
<object data="http://...">
Blocks it
Missing embed
<img srcset="http://..."> or inside <picture>
Blocks it
Broken image
<img src="http://...">
Upgrades it to https://
Image loads if the host serves HTTPS; warning in the console
<audio src>, <video src>, <source>
Upgrades it
Media loads if the host serves HTTPS
Any upgradable URL whose host is an IP address
Blocks it
http://93.184.215.14/logo.png fails
CSS needs care. MDN lists CSS image properties such as background-image as upgradable, and also lists every CSS url() value, naming background-image, as blockable. Do not rely on the upgrade: fix CSS URLs as if they will be blocked.
An upgrade is not a fix either. If the image host has no HTTPS, the upgraded request fails and the image breaks, and an http:// image in a srcset is not upgraded at all.
Where does mixed content usually hide?
It hides wherever a full URL was stored instead of a relative one: content saved in a CMS before the site moved to HTTPS, old embed codes, CSS files, environment variables and third-party snippets. So check the data behind each template, not only the template itself.
Where it hides
Typical example
How to fix it
CMS content and settings
Images and links in old posts saved as http://yoursite.com/wp-content/...; a site URL setting still on http://
Update the site URL, then rewrite stored URLs in the database
Old embeds
A video, map, form or widget snippet pasted years ago with http://
Replace it with the provider's current embed code
CSS
background-image: url(http://cdn.example.com/hero.jpg) or an @font-facesrc
Change to https:// or a relative path
Environment variables
API_URL=http://api.yoursite.com baked into the client bundle
Set https:// in every environment and rebuild
Third-party scripts
A tag manager tag or tracking pixel pointing at http://
Update the tag; remove it if the vendor has no HTTPS endpoint
Hard-coded absolute URLs in code
Image and script URLs built from an http:// base setting, or HTML copied from old email templates
Build URLs from one HTTPS base setting
User-generated content
Avatars or images users linked from other sites
Proxy or re-host them, or rewrite to https:// on save
How do you find mixed content in DevTools?
Open the page in Chrome, open DevTools, reload, and read the Console: each blocked or upgraded request is logged with its exact URL. Then filter the Network panel with mixed-content:all to list every affected request in one place, and check the Privacy and security panel for the page-level summary.
Open DevTools and select the Console panel.
In the Network panel, tick Disable cache, then reload, so cached responses do not hide requests.
Read each mixed content message. Blocked requests and auto-upgraded ones are logged separately, each with the full http:// URL.
In the Network panel, type mixed-content:all in the filter box. mixed-content:displayed narrows it to what was shown, and scheme:http lists every request made over plain HTTP.
Open the Privacy and security panel (it was called the Security panel before; open it from More tools, or from the command menu with "privacy"). It flags the page when resources come from non-secure origins and has a "View requests in Network panel" link that applies the filter for you.
Click through the page: open menus, play the video, submit the form. Requests made after load, such as fetch calls and lazy-loaded embeds, only appear once they happen.
Repeat on one page of each template (home, blog post, product, checkout), because mixed content usually lives in one template or one field.
To search a whole codebase at once, grep -rn "http://" src/ public/ shows every hard-coded insecure URL; ignore XML namespaces such as http://www.w3.org/2000/svg, which are identifiers, not requests.
How do you fix mixed content at the source?
Change each URL to https:// if the host supports it, or to a relative path if the file is on your own domain. Then find the setting or record that produced it, so the next page or post does not bring it back.
Your own assets: use relative paths (/images/hero.jpg) or build absolute URLs from one base setting that is https://.
WordPress: under Settings, General, set both WordPress Address (URL) and Site Address (URL) to https:// (if the fields are greyed out, change WP_SITEURL and WP_HOME in wp-config.php). Then rewrite stored URLs with WP-CLI: wp search-replace 'http://yoursite.com' 'https://yoursite.com' --skip-columns=guid --dry-run, check the report, and run it again without --dry-run. WP-CLI's docs say it handles PHP serialized data intelligently, so use it rather than editing the database by hand.
Other CMSs: export or query the content table for http://yourdomain, and update the rows through the CMS's own tools where possible.
Third-party embeds: get fresh embed code from the provider. If the provider only serves HTTP, remove the embed, because browsers will keep blocking it.
APIs: an http:// API base URL in an environment variable produces the classic "data does not load in production" bug, because every fetch to it is blocked. Set it to https:// and rebuild, since client-side environment values are written into the bundle at build time in frameworks such as Next.js and Vite.
After each fix, reload with DevTools open and confirm the console is clean.
Can upgrade-insecure-requests fix mixed content?
Yes, as a stopgap. Adding upgrade-insecure-requests to your Content-Security-Policy tells the browser to request every http:// subresource on your page over https://, including blockable ones. It works only for hosts that actually serve HTTPS, and it hides the underlying URLs rather than fixing them.
MDN also shows it as a <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> tag, which is useful when you cannot change headers. Use it while you clean the source data, then keep it as a safety net. The Content-Security-Policy starter guide includes it in a full policy.
Two related tools are easy to confuse with a fix:
An HTTP to HTTPS redirect does not help. Cloudflare's own docs say forcing HTTPS "does not resolve issues with mixed content, as browsers check the protocol of included resources before making a request." The browser blocks the http:// script before any redirect can run. The HTTP to HTTPS redirect guide covers what the redirect does fix.
Cloudflare's Automatic HTTPS Rewrites can rewrite some http:// links in HTML it proxies. Cloudflare says it resolves some mixed-content links, not all, so treat it like upgrade-insecure-requests: a backstop.
What about mixed downloads and localhost?
A mixed download is a file download started from an HTTPS page but fetched over http://, for example <a href="http://files.yoursite.com/guide.pdf" download>. MDN says browsers are expected to block these and commonly do by default, while letting the user keep or discard the file. Serve downloads from an HTTPS host like everything else.
Local development is the one place http:// is fine. MDN treats http://localhost, http://127.0.0.1 and file: URLs as secure origins, so a page loading assets from your local dev server is not mixed content. That is also why mixed content often appears only after deploy: a URL that worked against http://localhost:3000 becomes http://api.yoursite.com in production, and the browser blocks it.
Does mixed content affect security scores?
Yes, when your CSP allows it. The Mozilla HTTP Observatory takes 20 points when a CSP on an HTTPS site allows scripts or other active content over http:, and 10 when it allows only images or media over http:. It also takes 50 points when external scripts load over HTTP without Subresource Integrity.
Mixed content also undercuts the rest of your HTTPS setup. HSTS protects the page request, but a blocked stylesheet or an upgraded image that fails still breaks the page for the visitor. The security headers checklist covers the headers to send once the page itself is clean.
Check every page template for http:// resources
To check a live page without opening DevTools, run the free scan on LaunchScaler. It needs only your URL and no account, and three of its free checks look for this problem: http:// subresources on an HTTPS page, active mixed content that browsers will block, and insecure resources that degrade the page for search engines. They run with 156 checks across 6 of its 7 categories, alongside the HTTPS redirect, HSTS and CSP checks, so you can see every transport problem on the page in one report.
Find the http:// URL in the console message, then change it to https:// or a relative path at its source, whether that is your code, a CMS database field, an environment variable or a third-party embed. Add upgrade-insecure-requests to your CSP only as a stopgap while you fix the URLs.
03
Why do I get a mixed content warning on an image?
Browsers auto-upgrade an http:// image set with src and log a warning. If the image host does not serve HTTPS, the upgraded request fails and the image breaks. Images in srcset or picture elements are not upgraded; they are blocked.
04
Does HTTPS redirect fix mixed content?
No. The redirect upgrades pages people navigate to, but the browser checks a subresource's URL before requesting it, so an http:// script inside an HTTPS page is blocked before any redirect can happen.
05
How do I check a site for mixed content?
Open DevTools, reload, and read the Console for mixed content messages, then filter the Network panel with mixed-content:all. Repeat on each page template, since mixed content usually lives in one template or one CMS field.
Set metadataBase to the production domain, use opengraph-image, keep page openGraph objects from dropping the image, and test outside Vercel protection.
Most missing OG images are fetch failures: a relative URL, a blocked crawler, a login wall or tags added by JavaScript. Check each, then clear the cache.
Use 1200 x 630 px (1.91:1), PNG or JPEG, under 5 MB, with width, height and alt declared. How Facebook, LinkedIn and X crop it, and where to keep text.
