DigitalBanzai Knowledge

Mixed Content

Practical guide to understanding when an HTTPS page loads HTTP resources and how to fix insecure references.

Italian version
Severity
Moderate
Estimated fix time
10-30 min
Technical level
Beginner / Intermediate
Applies to
WordPressStatic SitesCMS / E-commerceCDN / Third-Party Embeds

Quick Answer

The Mixed Content check in the report detects whether an HTTPS page tries to load internal or external resources over insecure HTTP.

What it is

This is a focused, deterministic check. The scanner does not simply search for the string http:// everywhere in the text. It analyzes real loading contexts in the page HTML, such as scripts, stylesheets, images, iframes, and similar elements. Mixed content can affect how secure the connection appears, trigger browser warnings, or cause some resources to be blocked, but it is usually fixable with targeted changes.

How this is checked

The scanner parses the HTML of the analyzed page to identify HTTP resources that are actually loaded, or could be loaded, by the browser. The check isolates these contexts:

  • script[src] — external JavaScript files
  • link[href] — CSS stylesheets or preload-style relationships
  • img[src] — images embedded in the page
  • iframe[src] — embedded frames that load external pages or widgets
  • source[src], video[src], audio[src] — audio and video media files
  • object[data], embed[src] — embedded objects or plugins
  • style[url()] — resources such as background images referenced inside style blocks

What is not reported

To reduce false positives, the scanner explicitly ignores:

  • plain http:// URLs shown only as readable text on the page;
  • URLs inside HTML comments or CSS comments;
  • license links, author credits, or theme references;
  • textual metadata or namespaces that do not trigger resource loading.

The result shows whether the issue is present, how many resources were involved, which HTML tag and attribute were involved, the insecure URL, the scope (internal or external), and the status code of the analyzed page.

Why it matters

When an HTTPS page requests unencrypted elements, the consistency of the secure connection is partially undermined.

  • Active content can be blocked: modern browsers tend to block “active” resources such as scripts, stylesheets, and iframes when they are loaded over HTTP, to reduce the risk of tampering in transit.
  • Layout or features can break: if a CSS or JavaScript file is blocked, the page may render incorrectly or lose interactive behavior.
  • Browsers may show warnings: “passive” content such as images or video may still load, but it can affect browser security indicators or trigger warning signals in the address bar, reducing user trust.

Detecting mixed content does not mean the site is compromised or infected. It means there is a structural inconsistency that browsers can handle in different, sometimes disruptive, ways.

Possible results

The outcome depends on the state of the analyzed page:

  • No mixed content detected: no HTTP resource URLs were found in the analyzed loading contexts.
  • HTTP resources found on an HTTPS page: the report lists the exact code contexts where insecure references appear.
  • Only passive or media resources found: the finding is limited to images or audio/video files.
  • Active resources found: this deserves higher priority because scripts or stylesheets are more likely to be blocked by browsers.
  • Page not served over HTTPS: if the main page is served over HTTP, the mixed-content check may be informational only, because mixed content presupposes an HTTPS page as the starting point.

Priority depends on the type and origin of the detected resources:

  • Active resources (scripts, CSS, iframes, object/embed): higher priority. These are the elements browsers block more aggressively, so they should be fixed first.
  • Images and media: medium priority. They often still load, but they are commonly responsible for visible browser warnings.
  • External resources: review carefully. They depend on third-party domains, so it is worth confirming that the provider supports HTTPS before changing the URL.
  • Internal resources: standard priority. They are usually easier to fix because they live on the same server or CMS.
  • No mixed content detected: a good signal for the analyzed page. The page does not show mixed content in the analyzed contexts.

How to fix it

Removing mixed content usually means working through the source files or content-management layers methodically:

  1. Check the resource first: before changing the URL, confirm that the HTTP resource is still needed and actually reachable by manually replacing the prefix with https:// in the browser.
  2. Update the references: replace http:// with https:// directly in code or in the admin panel. Avoid broad blind search-and-replace operations, because some very old third-party services may not have a valid certificate and could stop working.
  3. Fix the code sources: update hardcoded references in templates, CSS, JavaScript, or plugin settings.
  4. Remove obsolete resources: if an external HTTP resource does not support HTTPS or is no longer available, consider removing it or replacing it with a modern alternative.
  5. Clear caches: after making changes, clear CMS, server, and CDN caches so the updated HTML is served.
  6. Run the scan again: rescan with the scanner to confirm that the issue has been resolved.

WordPress

On WordPress sites, mixed content can appear after a move from HTTP to HTTPS, or after changes to the theme, plugins, CDN settings, embeds, or content:

  • images and media files uploaded in the past whose absolute URLs are still stored as http:// in the database;
  • hardcoded links inside widgets, theme options, Customizer CSS, or older shortcodes;
  • rigid references generated by page builders or outdated plugins.

Recommended actions:

  • check that both WordPress Address (URL) and Site Address (URL) in Settings → General correctly use the https:// prefix;
  • use a dedicated search-and-replace tool to correct older URLs in the database while preserving serialized data integrity;
  • create a full database backup before any direct change;
  • test the homepage, contact forms, cart, and any checkout area after cleanup.

Static sites

On static sites or framework-generated sites such as HTML or Astro projects, insecure references usually live directly in the source files.

Recommended actions:

  • run a global search for the pattern http:// in the editor or code repository;
  • ignore plain text links and comments, and focus on resource-loading tags such as <script src="..."> or <img src="...">;
  • update the confirmed references to https://;
  • run a fresh build, deploy it to hosting, and test the published page.

How it appears in the report

The report presents the result in a readable way, separating the summary from the technical details.

Example with no mixed content detected

Mixed Content
Mixed content was not detected on the analyzed HTTPS page.
No HTTP resource URLs were detected in the parsed page HTML.
Review new templates, embeds, and stylesheets after content or theme updates.

{
  "scanned_url": "https://example.com",
  "final_url": "https://www.example.com/",
  "mixed_content_found": false,
  "count": 0,
  "resources": [],
  "status_code": 200
}

Example with mixed content detected

Mixed Content
The HTTPS page references resources loaded over HTTP.
Found 3 HTTP resource reference(s) in the parsed page HTML.
Active resources such as scripts, stylesheets, or iframes should be updated first.

  • script[src] → http://assets.example.com/app.js (external)
  • link[href] → http://assets.example.com/style.css (external)
  • style[url()] → http://cdn.example.com/background.jpg (external)

In the JSON details block, each resource is mapped with its context fields:

{
  "scanned_url": "https://www.example.com/",
  "final_url": "https://www.example.com/",
  "mixed_content_found": true,
  "count": 3,
  "resources": [
    {
      "tag": "script",
      "attribute": "src",
      "url": "http://assets.example.com/app.js",
      "scope": "external"
    },
    {
      "tag": "link",
      "attribute": "href",
      "url": "http://assets.example.com/style.css",
      "scope": "external"
    },
    {
      "tag": "style",
      "attribute": "url()",
      "url": "http://cdn.example.com/background.jpg",
      "scope": "external"
    }
  ],
  "status_code": 200
}

What this check does not verify

Mixed Content v1 is a focused HTML-structure analyzer and does not perform the following checks:

  • it is not a complete TLS or server-security audit;
  • it does not verify certificate installation quality or the expiry date of the main domain certificate;
  • it does not analyze performance impact or resource-loading speed;
  • it does not apply automatic fixes, rewrite code, or modify the site database;
  • it does not guarantee that the whole site is free of mixed content, because the check is limited to the analyzed page or the analyzed page sample;
  • it does not evaluate the internal security level of third-party servers that host detected external resources;
  • it does not download or deeply inspect the internal code of external scripts to look for additional dynamic calls.

Summary

The Mixed Content check in the report is a consistency check that helps keep the benefits of HTTPS aligned with the resources a page actually loads. If HTTP resources are detected, it makes sense to prioritize active content such as scripts, CSS, and iframes, then move on to images and media. If the check does not find anomalies, the analyzed page does not show mixed content in the analyzed contexts. It is still good practice to repeat the test after structural changes, theme updates, or new external widgets.