Mixed Content: Insecure Resources on an HTTPS Page

Your site loads over https://, the padlock shows, and you assume the connection is locked down. Then one <img>, one third-party <script>, or one stylesheet still points at http:// — and the browser quietly downgrades that part of the page. That is mixed content, and it is the most common reason a "secure" page still shows a broken padlock, a console warning, or a blocked resource. For an indie developer or store owner who just moved everything to HTTPS, it is an easy gap to miss because the page usually still looks fine.

This page explains exactly what mixed content is, what LaunchTrust looks for, and how to clean it up before you submit an app, list a store, or send a launch link to anyone who will inspect it.

What LaunchTrust checks

The mixed_content detector inspects the HTML of the page you scan and looks for insecure subresources — resources the browser actually loads — that point at http:// while the page itself is served over HTTPS. Specifically, it scans for:

• An src attribute beginning with http:// on a loaded element: <img>, <script>, <iframe>, <audio>, <video>, <source>, <embed>, or <track>.
• An href attribute beginning with http:// on a <link> tag (for example, a stylesheet pulled in over plain HTTP).
• A srcset attribute that contains an http:// URL (responsive image candidates).

It deliberately ignores plain navigation links (<a href="http://...">) and namespace or schema URLs such as xmlns and itemtype — those are identifiers, not resources the browser downloads, so they do not cause a mixed-content downgrade.

This detector's polarity is risk: the thing it hunts for is something you do not want present. Here is how to read the three signals:

• Detected (severity: medium) — at least one insecure http:// subresource reference was found in the HTML. The signal includes a short snippet of the offending tag so you can locate it. This is the result to act on.
• Not detected (severity: info) — no insecure http:// resource references were found in the scanned HTML. A clean signal here, not a guarantee that every dynamically injected resource is secure.
• Unable to determine — the page was not served over HTTPS, so a mixed-content check does not apply. (A plain-HTTP page has no "secure context" to mix into; the relevant signal there is the HTTPS check itself.)

A few honest limits: LaunchTrust reads the HTML as delivered. Resources injected later by JavaScript, loaded inside iframes, or requested from inside a single-page app after hydration may not appear in the initial markup. A "not detected" result narrows the risk; it does not exhaustively prove the absence of every insecure request.

Why it matters

Mixed content is a security best practice issue with very visible consequences:

• Browsers block or downgrade it. Modern browsers block active mixed content (scripts, iframes, stylesheets) outright, and auto-upgrade or block passive mixed content (images, media). A blocked script can break layout, payments, analytics, or login.
• It defeats the point of HTTPS. An insecure subresource travels in plaintext and can be read or tampered with in transit, even though the main document is encrypted. For pages that handle personal data, an insecure subresource keeps part of that traffic unencrypted, which is generally something reviewers and privacy-minded users expect you to avoid.
• It is a credibility signal at review time. A reviewer, partner, or security-conscious user who opens dev tools and sees mixed-content warnings forms an immediate impression about how carefully the surface was built.

Fixing it is usually cheap, and the payoff is a clean console and a padlock that means what it says.

A concrete example

A detected signal typically points at something like a hard-coded http:// URL left over from a pre-HTTPS template:

<script src="http://cdn.example.com/widget.js"></script>
<link rel="stylesheet" href="http://fonts.example.net/...REDACTED.css">
<img src="http://images.example.com/hero.png">

Each of these forces an insecure request from an otherwise secure page. The fix is almost always to change http:// to https:// (or to a protocol-relative //), assuming the host serves the resource over TLS — which most do today.

How to address it

1. Find every insecure reference. Open the page in a browser, open the developer console, and reload. Mixed-content warnings name the exact URLs. Use the snippet in the LaunchTrust signal as a starting pointer.
2. Switch http:// to https://. For each flagged src, href, or srcset URL, request the same resource over HTTPS. Confirm the host actually serves it securely (most CDNs and asset hosts do).
3. Sweep your source, not just one page. Search your templates, components, and config for the literal string http:// to catch references that did not render on the page you scanned. Hard-coded asset URLs and third-party embeds are the usual culprits.
4. Check what JavaScript injects. Inspect any widgets, tag managers, or ad/analytics snippets that build URLs at runtime, since those can introduce insecure requests the static HTML never shows.
5. Add a backstop. Consider a Content-Security-Policy with upgrade-insecure-requests, which tells browsers to silently retry http:// subresource requests over HTTPS. Treat this as a safety net, not a substitute for fixing the source.
6. Re-scan to confirm the signal clears. After the changes, run the page again and verify the result moves to "not detected."

Check this in 30 seconds

Paste your URL into the free LaunchTrust scanner. It reads your page's HTML and tells you whether any insecure http:// images, scripts, stylesheets, or media are being loaded on your HTTPS page — with a snippet of the exact tag so you know where to look. No account required to run a check, and it pairs naturally with the HTTPS transport and security headers checks.

FAQ

What exactly counts as mixed content? An HTTPS page that loads at least one resource — image, script, stylesheet, iframe, media — over plain http://. Plain navigation links to http:// pages do not count, because the browser does not load them as part of the secure page.

Why does my padlock look broken even though my URL starts with https? Almost always one insecure subresource. The document is encrypted, but a single http:// image or script triggers the browser's mixed-content warning. Find and upgrade that reference and the padlock returns to normal.

Does a "not detected" result mean my page is fully secure? No. It means no insecure http:// subresources were found in the HTML LaunchTrust scanned. Resources injected by JavaScript after load, or inside iframes, may not be visible to a static scan. Use it as a strong narrowing signal, not a clean bill of health.

Does clearing this check prove my site or app meets the rules? No. LaunchTrust reports a signal — whether insecure subresources were detected — not a verdict, score, or certification. It is a compliance aid, not legal advice, and clearing this check does not by itself satisfy any legal or store requirement. Insecure transport is just one of many things reviewers and regulators may look at.

Compliance aid, not legal advice. LaunchTrust reports signals, not a verdict or certification.