Mixed Content Checker: Find HTTP Resources on HTTPS Pages

To find HTTP resources on an HTTPS page, reload the page with your browser developer console open and inspect mixed-content warnings. The warning identifies the requesting page, the HTTP resource, and whether the browser upgraded or blocked the request. For a whole site, combine browser inspection with a crawler or URL checker, then retest the real pages and user flows.

Mixed content means an HTTPS page requests a resource over HTTP or another insecure protocol. That request can expose data to observation or modification in transit, weakening the security of the page. See MDN’s mixed-content guidance.

1. Check one HTTPS page in a browser

Open the affected https:// URL.
Open Developer Tools and select the Console tab.
Reload the page with the console visible.
Filter for Mixed Content, http://, blocked, or upgraded.
Copy the exact resource URL and its type: script, stylesheet, image, font, iframe, request, media, or another asset.
Open the Network tab, reload again, and confirm the request’s final status, initiator, and response.

Chrome’s Lighthouse documentation points to the DevTools Security panel for debugging HTTPS and mixed-content problems: Does not use HTTPS. The console shows requests that the browser actually attempted during that page load, including requests created by JavaScript.

What the browser may do

Modern browsers distinguish upgradable content from blockable content. Images, some CSS image URLs, audio, and video can be upgraded from HTTP to HTTPS. Scripts, stylesheets, iframes, web fonts, fetch(), XMLHttpRequest, and several other request types are generally blockable. An upgradable request can still fail when the HTTPS endpoint does not serve the resource, and an HTTP URL using an IP address may be blocked even when its resource type is otherwise upgradable.

Finding	Meaning	Next action
Upgraded	The browser changed the request to HTTPS.	Make the source URL explicitly HTTPS and verify the secure endpoint works.
Blocked	The insecure request was refused.	Replace the URL, update the provider, or remove the dependency.
Loads successfully	The browser allowed or upgraded it, but the source is still stale.	Fix the reference so behavior does not depend on browser upgrading rules.

2. Find references across a site

A browser session answers “what did this page request?” A recursive crawler or online checker answers “which pages contain HTTP references?” Use both when the site has templates, CMS content, JavaScript rendering, or authenticated routes.

Option A: crawler or online checker

Enter the HTTPS site or start URL.
Allow the checker to follow internal links when you need a site-wide inventory.
Record each HTTP resource URL, the page that referenced it, resource type, and status.
Separate static references from runtime requests.
Open representative pages in a browser and repeat the console and Network checks.

MDN lists HTTPSChecker, mcdetect, and an online Mixed Content Checker as examples of checking paths. Treat named tools as examples, and verify their current maintenance, privacy, and coverage before sending a production site through them: MDN mixed content.

Option B: inspect source and generated markup

Search templates, CMS fields, CSS, JavaScript, feeds, and stored content for absolute HTTP URLs:

rg -n --hidden --glob '!node_modules' --glob '!vendor' 'http://' .

This catches many stale references but cannot prove that no runtime request exists. JavaScript may construct a URL after load, and a service worker or third-party widget may request resources that are absent from the initial HTML.

Option C: inspect a saved page response

curl -sS -L 'https://example.com/page' | rg -n 'http://'

This is useful for server-rendered HTML. It does not execute scripts, load CSS, follow lazy resources, or authenticate, so it must be followed by a browser check.

3. Understand the URL that caused the warning

Record four values before editing anything:

Request URL: the exact http:// address.
Requesting page: the HTTPS page or route that loaded it.
Resource type: script, stylesheet, image, iframe, font, media, or programmatic request.
Initiator: the HTML element, stylesheet, script, or third-party component that created the request.

A normal link that navigates the top-level page to an HTTP destination is not a mixed-content subresource request. Insecure downloads are a separate browser security concern. Keep your checker focused on resources loaded into the HTTPS document, while reviewing downloads separately if they matter to your site.

4. Fix the underlying reference

For a first-party asset, configure the server or CDN to serve it over HTTPS.
Change page templates, CMS content, CSS, and generated URLs from http:// to https:// or a same-site relative URL such as /assets/app.css.
For a third-party asset, check whether the provider offers an HTTPS URL. If not, replace the dependency with a secure alternative or remove it.
Reload the affected page and confirm the resource loads correctly.
Rerun the site crawl and sample dynamic, logged-in, and checkout flows in a browser.

Examples

<!-- Stale -->
<script src="http://cdn.example.com/app.js"></script>

<!-- Explicit HTTPS -->
<script src="https://cdn.example.com/app.js"></script>

<!-- Same-site relative URL -->
<link rel="stylesheet" href="/assets/site.css">

Do not disable browser mixed-content protection. If a provider cannot serve an asset securely, the safe choices are replacement or removal.

5. Use CSP as a safety net

The Content-Security-Policy upgrade-insecure-requests directive asks browsers to upgrade insecure requests, including requests that would otherwise be blockable. It can reduce breakage while you repair stale URLs, but it does not prove that the HTTPS endpoint exists or that the returned content is correct.

Content-Security-Policy: upgrade-insecure-requests

Deploy it only after reviewing the affected resources and monitoring the result. MDN marks block-all-mixed-content as deprecated and says modern mixed-content handling makes it unnecessary: block-all-mixed-content directive.

6. Capture a clean record of the affected page

A screenshot helps document what users saw before and after a fix. You can use browser automation for an internal workflow, or use ScreenshotNeo to capture the HTTPS page directly.

Or skip the browser setup

ScreenshotNeo accepts one GET request and returns a PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing result. It also provides an MCP server for AI agents, with take_screenshot, get_page_info, and capture_pdf.

See the ScreenshotNeo API documentation for options such as full-page capture, element selectors, device presets, custom CSS and JavaScript, waits, blocked requests, headers, cookies, geolocation, caching, signed links, asynchronous jobs, bulk capture, and usage reporting.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page -o mixed-content-check.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page"},
    timeout=90,
)
r.raise_for_status()
open("mixed-content-check.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/page'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
require('fs').writeFileSync('mixed-content-check.webp', image);

1,000 screenshots a month are free with no card. Paid plans start at $5 for 3,000 shots, and every feature is available on every plan. Create a free ScreenshotNeo account.

7. Troubleshooting common mixed-content errors

Symptom	Likely cause	Fix
“Mixed Content: The page was loaded over HTTPS…”	An HTML, CSS, or script reference still uses HTTP.	Use the console’s URL and initiator to update the source template or asset.
Image appears, but script or font is missing	The image was upgradable; the script or font was blockable.	Serve every dependency over HTTPS instead of relying on automatic upgrades.
Changing `http` to `https` causes 404 or certificate errors	The host does not serve that path securely, or its certificate is invalid.	Verify the HTTPS endpoint directly, fix the server/CDN, or replace the resource.
No warning in page source, but the console reports one	JavaScript, CSS, a widget, or a service worker created the request at runtime.	Use Network initiators and test the real interaction that triggers it.
Crawler reports HTTP, but browser does not	The browser upgraded the request automatically.	Still update the stale reference, then rerun both checks.
Only logged-in users see the warning	The affected route or component requires authentication.	Run an authenticated browser journey and crawl protected templates separately.
Resource uses an IP address	Browsers may block an otherwise upgradable request when its host is an IP.	Use a valid HTTPS hostname and certificate.

8. Reliability, performance, and maintenance

Prefer exact evidence: save the page URL, resource URL, type, initiator, and timestamp for each finding.
Separate static and runtime coverage: source scans and crawlers find references; browser sessions reveal requests created after JavaScript runs.
Control crawl load: use a bounded URL set and respect your site’s capacity, especially on staging or authenticated environments.
Retest after dependency changes: third-party scripts, tag managers, widgets, and CDNs can reintroduce HTTP URLs.
Use CSP carefully: upgrade-insecure-requests can reduce breakage, but URL correction remains the durable fix.
Keep evidence for regressions: compare console output, Network requests, and screenshots before and after deployment.

9. A repeatable mixed-content checklist

Open the HTTPS page with Console and Network visible.
Record every HTTP resource and its initiator.
Search templates, CMS data, CSS, JavaScript, and generated markup for http://.
Run a recursive checker for site-wide references.
Test dynamic and authenticated journeys in a real browser.
Move first-party and third-party dependencies to working HTTPS endpoints.
Use upgrade-insecure-requests only as supporting policy.
Confirm resources still load and the console is clean.
Repeat the crawl after deployment.

FAQ

Can I fix mixed content by adding an SSL certificate?

An HTTPS certificate secures the host, but stale page references still need to point to an HTTPS URL and the endpoint must serve the requested path.

Why does the page look correct while the console reports mixed content?

The browser may have upgraded an upgradable resource. The reference remains insecure and can fail in other browsers, with other resource types, or when the HTTPS endpoint is unavailable.

Does a mixed-content checker replace browser testing?

No. A crawler is useful for breadth, while DevTools observes requests made during actual rendering and interaction. Use both for dynamic or authenticated pages.

Should I use `block-all-mixed-content`?

No as a default fix. MDN marks it deprecated; repair the URLs and consider upgrade-insecure-requests as a supporting policy.