HTTPS, SSL & Security
What is a mixed content warning?
A mixed content warning is a browser security alert that appears when a webpage loaded over HTTPS attempts to load resources, images, scripts, stylesheets, iframes, or other assets, over insecure HTTP. The page itself was delivered securely over an encrypted connection but some of its component resources are being requested over an unencrypted channel, creating a mix of secure and insecure content on the same page. This mixing of HTTPS and HTTP content on the same page is what gives the warning its name.
Mixed content is a security concern because HTTPS provides security guarantees, encryption, authentication, and integrity, that depend on the entire page being delivered securely. When resources are loaded over HTTP those resources can be intercepted and modified by an attacker on the network path. An attacker who can intercept an HTTP JavaScript file loaded by an HTTPS page can modify the script to do anything, steal credentials, redirect users, inject malicious content, regardless of the fact that the page itself was loaded securely. The security of an HTTPS page is only as strong as its least secure resource.
Mixed content warnings are encountered when migrating websites from HTTP to HTTPS, the most common cause is hardcoded HTTP URLs in HTML, CSS, or JavaScript that were never updated when the site switched to HTTPS. They also appear when third-party resources, analytics scripts, advertising networks, embedded content, are served over HTTP rather than HTTPS. Understanding mixed content, its different types, and how to identify and fix it is essential for anyone managing HTTPS websites and redirect infrastructure.
Types of mixed content
Mixed content comes in two distinct categories, active mixed content and passive mixed content, distinguished by the type of resource being loaded over HTTP and the severity of the security risk each creates.
Active mixed content: resources that can actively modify the page’s Document Object Model, the programmatic representation of the page’s content and structure, or execute code. Scripts, stylesheets, iframes, XMLHttpRequest calls, and fetch requests are all active mixed content when loaded over HTTP.
Active mixed content represents the highest security risk. A maliciously modified JavaScript file can steal authentication cookies, capture form inputs, redirect users to phishing sites, or perform any other action that legitimate JavaScript can perform. A modified stylesheet can overlay fake login forms on top of legitimate content. The potential for damage from active mixed content is essentially unlimited, an attacker who can modify a single JavaScript resource can fully compromise the security of an HTTPS page.
Modern browsers block active mixed content entirely, the resource is not loaded at all. The browser does not display the content that would have come from the HTTP resource and shows a security indicator indicating blocked content. This blocking prevents the security compromise but may break page functionality if the blocked resource was essential to the page.
Passive mixed content: resources that are displayed on the page but cannot modify its content or execute code. Images, audio files, and video files are passive mixed content when loaded over HTTP. A maliciously modified image can only replace the expected image with a different one, it cannot execute code or access the DOM.
Passive mixed content represents a lower but still real security risk. An intercepted image can be replaced with misleading content, a fake padlock image claiming the page is secure when it is not, offensive imagery replacing legitimate content, or simply broken page appearance when content is blocked. The integrity of the page’s visual presentation is compromised even if the JavaScript security is not.
Modern browsers handle passive mixed content less aggressively than active mixed content, some browsers display the content while showing a modified security indicator. The padlock icon in the address bar may show a warning symbol rather than the standard padlock to indicate that some content was loaded insecurely. Other browsers block passive mixed content as well. Browser behaviour toward passive mixed content has been moving toward blocking, the distinction between active and passive is less significant than it was previously.
Optionally blockable vs blockable: the W3C Mixed Content specification uses slightly different terminology, blockable content for what is described here as active mixed content that must be blocked, and optionally blockable content for passive mixed content that browsers may choose to block or allow. The practical effect is similar, browsers block the most dangerous mixed content unconditionally and are increasingly blocking the less dangerous content as well.
Common causes of mixed content
Understanding why mixed content occurs helps with both prevention and remediation.
Hardcoded HTTP URLs in content: the most common cause of mixed content after migrating from HTTP to HTTPS. Content in the database, articles, pages, posts, contains hardcoded HTTP URLs for images, links to internal pages, or embedded media. After the site switches to HTTPS these hardcoded URLs still use HTTP, creating mixed content for every page that contains them.
For sites with large content databases, hundreds of thousands of articles or product pages, auditing and updating every hardcoded URL is a significant undertaking. Database-level find-and-replace operations update URLs in bulk but must be performed carefully to avoid breaking legitimate HTTP links to external resources.
Hardcoded HTTP URLs in templates and code: themes, templates, and application code may reference resources using hardcoded HTTP URLs. A stylesheet that loads a background image from http://example.com/image.png creates mixed content on every page that includes the stylesheet. Code audits and testing after HTTPS migration identify template-level mixed content.
Third-party resources served over HTTP: analytics scripts, advertising networks, social media widgets, embedded maps, and other third-party resources may be served over HTTP rather than HTTPS. The page owner cannot force the third party to serve over HTTPS, if the third party does not support HTTPS the only option is to remove the resource or host a local copy over HTTPS.
Modern third-party services almost universally support HTTPS, major analytics platforms, advertising networks, and widget providers have supported HTTPS for years. Resources from third parties that do not support HTTPS should be removed from HTTPS pages.
User-generated content: content submitted by users, comments, profile images, embedded media, may contain HTTP URLs. A user who embeds an image using an HTTP URL in a comment creates mixed content on any HTTPS page displaying that comment. Content management systems should normalise user-generated URLs to HTTPS or block HTTP resource embedding.
Protocol-relative URLs: historically some developers used protocol-relative URLs, //example.com/resource without the https: or http: prefix, which use whatever protocol the page was loaded over. On HTTP pages these resolve to HTTP. On HTTPS pages they resolve to HTTPS. Protocol-relative URLs do not cause mixed content, they are a useful technique for ensuring resources use the same protocol as the page. However they do not upgrade HTTP resources to HTTPS, if the resource is only available over HTTP the protocol-relative URL still loads it over HTTP.
Identifying mixed content
Finding mixed content requires inspecting browser network requests and testing pages thoroughly after HTTPS migration.
Browser developer tools: the most immediate tool for identifying mixed content on specific pages. The Console tab shows mixed content warnings with the URL of the mixed content resource and the type of mixed content. The Network tab shows all requests made by the page, filtering by protocol allows identifying HTTP requests made from an HTTPS page. The Security tab summarises the page’s security status, indicating whether mixed content was detected and what type.
Chrome, Firefox, Edge, and Safari all provide mixed content information in their developer tools. Testing each major page template, homepage, article pages, product pages, checkout pages, with developer tools open identifies the mixed content patterns that need to be fixed.
Crawling tools: automated crawling tools, Screaming Frog, Sitebulb, and similar, can crawl an entire site checking for mixed content across all pages. These tools make HTTP requests for every page and analyse the responses for mixed content indicators, identifying mixed content at scale across large sites where manual page-by-page testing would be impractical.
Content Security Policy reporting: Content Security Policy, CSP, headers can be configured in report-only mode to collect information about mixed content violations without blocking them. A Content-Security-Policy-Report-Only header with an upgrade-insecure-requests or block-all-mixed-content directive and a report-uri endpoint collects reports whenever mixed content would be blocked, providing a comprehensive log of mixed content violations across all page visits.
Fixing mixed content
Fixing mixed content requires updating all HTTP resource URLs to HTTPS equivalents, either by changing the URL scheme or by finding HTTPS-hosted versions of the resources.
Update internal resource URLs: for resources hosted on the same domain as the page, images, scripts, stylesheets, simply changing the URL scheme from HTTP to HTTPS resolves the mixed content. http://example.com/image.jpg becomes https://example.com/image.jpg. For content stored in a database bulk updates change HTTP URLs to HTTPS. For template and code references systematic find-and-replace updates the URLs.
Use relative URLs for same-origin resources: the most robust approach for internal resources. A relative URL, /image.jpg or ../styles/main.css: uses the same protocol as the page automatically, HTTPS on an HTTPS page, HTTP on an HTTP page. Relative URLs eliminate the protocol hardcoding problem entirely, they never need to be updated when switching between HTTP and HTTPS.
Update third-party resource URLs to HTTPS: for third-party resources change the URL from HTTP to HTTPS if the third party supports HTTPS. Most modern third-party services do. Simply changing http:// to https:// in the embed code tests whether the HTTPS version is available.
Use the upgrade-insecure-requests CSP directive: the Content Security Policy upgrade-insecure-requests directive instructs browsers to automatically upgrade all HTTP resource requests to HTTPS, treating every HTTP resource URL as if it were HTTPS. This is a powerful mitigation for legacy content with hardcoded HTTP URLs that cannot be immediately updated. Adding the header:
Browsers that receive this directive attempt all HTTP resource requests as HTTPS. Resources available over HTTPS are loaded correctly, the mixed content problem is resolved. Resources only available over HTTP fail to load, making the upgrade-insecure-requests directive unsuitable for sites with resources that genuinely only exist over HTTP.
Remove or replace HTTP-only third-party resources: if a third-party resource is only available over HTTP and cannot be upgraded remove it from HTTPS pages or replace it with a self-hosted HTTPS alternative. An HTTP-only resource that cannot be upgraded is incompatible with a secure HTTPS page, it must be removed to achieve clean HTTPS.
Mixed content and redirect management
Mixed content intersects with redirect management in specific ways, both in how redirects can cause or prevent mixed content and in how redirect infrastructure must be configured to avoid it.
Redirect destination mixed content: the destination of a redirect must be a fully clean HTTPS page for the redirect to deliver visitors to a secure experience. A redirect from https://old-domain.com to https://new-domain.com that lands on a page with mixed content defeats the purpose of HTTPS throughout the redirect chain. Auditing the destination site for mixed content is part of complete redirect management.
HTTP redirect destinations: a redirect that sends visitors from an HTTPS source to an HTTP destination creates an inherent security downgrade. The browser may display a warning about the connection changing from secure to insecure. The destination page is fully insecure, not just mixed content but entirely HTTP. All redirect destinations should be HTTPS URLs, the final destination of any redirect chain must be HTTPS.
Canonical HTTPS enforcement: redirect management that enforces HTTPS, redirecting all HTTP requests to HTTPS equivalents, prevents the creation of HTTP pages that could be indexed by search engines or bookmarked by users. When only the HTTPS version of a page exists mixed content on that page is the only remaining HTTPS concern, the HTTP version of the page does not exist to create separate indexation issues.
SSL termination and mixed content: when SSL is terminated at a proxy or load balancer the backend application receives HTTP requests regardless of whether the original client connection was HTTPS. If the application generates page content using the connection protocol, building URLs as HTTP because the connection to the backend is HTTP, it creates mixed content even though the client connection was HTTPS. The X-Forwarded-Proto header communicates the original protocol to the backend, applications behind SSL termination must use this header when generating URLs to ensure HTTPS URLs are generated for HTTPS client connections.
Mixed content and SEO
Mixed content has several SEO implications, primarily through its effect on the security signals that search engines use as ranking factors.
HTTPS ranking signal: Google uses HTTPS as a ranking signal. A page served over HTTPS with clean HTTPS resources receives the full benefit of this signal. A page with mixed content, even if the page URL itself is HTTPS, may receive a reduced signal because the page is not fully secure. While the precise effect of mixed content on Google’s HTTPS signal is not publicly documented the general principle that security quality affects the signal is reasonable.
Browser blocking affecting crawlability: when browsers block active mixed content, JavaScript files loaded over HTTP, page functionality may be impaired. Search engine crawlers use browser-like rendering engines, if mixed content blocking causes rendering issues that affect content visibility crawlability and indexation quality may be affected.
Security indicator affecting user trust: mixed content warnings modify the browser’s security indicator, replacing the standard padlock with a warning indicator. Users who notice this change may distrust the page and leave, increasing bounce rates and decreasing engagement signals. These engagement effects have indirect SEO consequences.