Mixed Content Link Scanner — Find HTTP References on HTTPS Pages

A mixed content checker identifies HTTP resource references in HTML that is intended to load over HTTPS. Paste a page markup or inspect a public HTTPS page through the restricted server endpoint, then review insecure asset URLs in elements, source sets, inline styles, and selected JavaScript string literals. Results distinguish hardcoded references from literals associated with possible runtime requests, and failed live inspections are reported as failures rather than empty scans. This is a static-source inspection: external scripts, dynamically assembled addresses, CSS imports beyond supplied HTML, browser upgrades, and actual network behavior require separate verification.

Mixed Content Checker At a Glance

Why Mixed Content Matters for Secure Pages

A website served over HTTPS promises encrypted transport for its primary document, but that promise becomes incomplete when the page also requests insecure HTTP resources. Depending on the resource type and current browser behavior, the request may be blocked, upgraded to HTTPS, or treated with special restrictions. Scripts and certain other active resources have historically posed especially serious risks because an attacker on the network could alter executable content. Even a blocked reference can cause broken visuals or inaccessible functionality. Reviewing resource URLs is therefore part of both transport security and practical website quality assurance, not simply a matter of removing an outdated prefix from a stylesheet.

What Counts as a Hardcoded Resource Reference

HTML exposes numerous places where a resource address may appear. The scanner checks common attributes such as img src, script src, iframe src, video poster, object data, form action, and relevant link href values. It also examines srcset candidates and explicit HTTP URLs inside inline style declarations or style blocks. Each finding identifies the element, attribute, reference, and resolved resource URL. The scanner deliberately does not treat every ordinary hyperlink as an actively loaded resource, because navigating to an HTTP page after a user clicks is a different behavior from loading an HTTP script into the current HTTPS document.

Resolving Relative Links Against a Base URL

A browser resolves relative resource references using document URL rules, sometimes modified by a base element. This checker requires an HTTPS base address so it can interpret resource URLs consistently, while focusing its report on explicit HTTP references. A relative image path such as /images/header.png normally inherits the secure HTTPS origin and is not classified as an insecure reference. An explicitly written http:// address is a different situation. A protocol-relative URL beginning with two slashes ordinarily inherits the document's scheme and is not automatically insecure on an HTTPS page. Review unusual base-element configurations manually because static resolution and runtime document behavior can differ.

Live Inspection Versus Offline Source Analysis

In offline mode, the scanner analyzes the HTML you paste and labels its findings as source-level observations. Live mode asks the site's restricted PHP endpoint to retrieve one page and only proceeds when an actual successful HTTP response and HTML body are returned. The endpoint applies public-address checks, response limits, redirect rules, and other protective constraints. If a site blocks the request, the report does not claim that no mixed content exists. Live retrieval can still differ from a full browser render because JavaScript may inject resources after load or a CDN may supply alternate HTML under different conditions.

Separating Static URLs From JavaScript-Literal Requests

Some inline scripts contain obvious HTTP strings passed to a network API. The scanner labels selected literals in calls such as fetch separately from ordinary image or stylesheet attributes. This is intentionally modest evidence: the presence of a string does not prove that the call executes, and the absence of a string does not prove that no insecure request can occur. Code can build URLs dynamically, import external modules, or use configuration delivered after page load. Those behaviors belong in a browser network trace or instrumented test, not a report based on regular expressions applied to markup.

What Browsers Do With Insecure Assets

Modern browsers frequently block active mixed content and can attempt to upgrade some passive resource types to HTTPS. A successful upgrade depends on the destination actually supporting secure transport; a request that looks harmless in source can still fail at runtime. Content Security Policy can also introduce rules that influence upgrades or block loading. Because these decisions depend on browser versions, deployment configuration, and resource category, a static finding is best treated as something to investigate rather than an automatic guarantee of exploitation. Open the actual page over HTTPS, inspect the console and network panel, and record which resources were attempted, upgraded, blocked, or successfully fetched.

Example: Auditing a Landing Page After a Migration

Suppose a landing page has moved to HTTPS but its HTML still includes an HTTP hero image, an HTTPS CSS bundle, and a hardcoded HTTP API call inside an inline script. The scanner lists the image under static resource references and identifies the API address as a runtime-related literal. It does not classify the secure CSS bundle as a problem. The developer can then check whether the image has an HTTPS endpoint, whether the API server supports encryption, and whether any script actually executes the request. The correct repair is normally to use reliable HTTPS destinations and test the application, not to hide the warning while keeping an insecure dependency.

Working With Source Sets and CSS URLs

Responsive images can contain several candidate URLs inside srcset, any of which a browser may choose according to display density and viewport width. The scanner examines those candidates individually rather than considering only the primary img src attribute. Inline CSS may also contain background images and imported stylesheets that are not visible from ordinary link-element inspection. This tool checks literal URLs within supplied style blocks, but it does not recursively download referenced stylesheets to discover all nested imports. A thorough audit should inspect the final CSS delivered to browsers and include viewport variations that select different image candidates.

Interpreting an Empty Report Responsibly

If no explicit HTTP references are found, the report means only that none were detected within the inspected source and supported patterns. A third-party script might introduce an insecure request, a URL could be constructed by concatenating strings, or a resource could be loaded conditionally after a user interaction. Similarly, inaccessible pages must not be marked clean. Combine the static scan with developer-tool network inspection and tests of important workflows such as checkout, contact forms, authentication, and video playback. The absence of one class of finding is useful evidence but should not become a universal security assertion.

Prioritizing Repairs and Recording Evidence

Start with insecure executable resources and endpoints that handle user information, then evaluate images, stylesheets, media, and ancillary assets according to their impact. For each finding, document the page URL, actual resource address, request type, and observed browser behavior. JSON export preserves the scanner's source classification and original references for technical tickets. A careful URL parser can separate an address into its components when tracking down redirects and protocol changes, but policy and runtime behavior still require independent investigation. The most durable fix is to deliver the necessary resources securely and validate the result under the same conditions real visitors use.

Testing Redirects and Infrastructure Rewrites

An asset URL that begins with HTTPS may still redirect, while an old HTTP URL might be automatically upgraded by the browser before any network request is transmitted. Neither possibility is established by reading the original markup alone. When a static finding matters, request the asset manually using a trusted inspection workflow, confirm its redirect chain, verify the final response's certificate and MIME type, and review whether it uses cookies or credentials. Check any site-wide Content Security Policy and HTTP-to-HTTPS redirect configuration as separate layers of evidence. A successful homepage scan is particularly easy to overinterpret when the application serves different markup on product, checkout, account, and localized pages. Build a repeatable set of representative URLs and test their real network traffic after deployments, including mobile breakpoints and consent-state variations that can introduce new third-party scripts.

Frequently Asked Questions About Mixed Content Checker