Mixed Content Checker

Mixed content occurs when a securely loaded page uses resources requested over an insecure connection. Screpy's Mixed Content Checker finds HTTP resource references in one public HTTPS page's source HTML, then shows their category, address, first source line and occurrence count. Use those details to locate the content or template that needs changing and prepare a secure replacement.

The report does not execute the page or fetch the listed resources. It identifies source references to investigate, not a record of what a visitor's browser actually loaded, upgraded or blocked. A successful check also does not certify the whole website's security.

Check the HTTPS page that contains the references

Enter the complete public address of the page you want to inspect. For an article, submit that article's URL, such as the illustrative https://example.com/guides/setup/, rather than the homepage or the image you suspect is insecure. This tool examines one supplied page; it does not discover every page on the domain.

The input requires HTTPS. After the check, read the final URL because redirects can change the page being inspected. If an HTTPS address ends at HTTP, the report is not applicable to HTTPS mixed-content analysis. That is not a clean result. Use the Redirect Checker to investigate an unexpected destination.

The page must return readable public HTML. A login screen can contain different references from the private page behind it. An unavailable response, unsupported document or failed request leaves the requested check incomplete; it does not establish that no insecure references exist.

Read blockable resources, upgrade candidates and form targets

Use the category filter to focus the table, then review the element and attribute beside each address. The categories describe how this checker groups supported HTTP references; they are not observed browser outcomes.

The checker also examines supported resource references such as objects, image inputs, video posters and selected link relations. Image or media URLs with an IP-address host are placed in the blockable category rather than upgrade candidates.

Current mixed-content guidance distinguishes upgradeable and blockable requests. Actual behavior also depends on browser rules and security policies. This source classification does not evaluate every exception, including potentially trustworthy local addresses. Do not treat every red row as proof that a particular browser blocked a request.

Form targets are a separate review category. The mixed-content specification's form-submission section describes browser warnings as distinct from ordinary resource checks. Screpy never submits these forms or determines what information they collect. Review a real form's purpose without sending sensitive test data to an unverified destination.

Trace grouped findings back to the source

The table combines occurrences sharing the same element, attribute, classification and resolved URL. The same address in a different element or attribute can therefore occupy another row. The displayed line is the group's first occurrence in the fetched HTML, not necessarily a line in your template editor.

This fictional fragment contains four HTTP references:

<script src="http://static.example.com/site.js"></script>
<img src="http://static.example.com/logo.png" alt="Example homepage">
<img src="http://static.example.com/logo.png" alt="Example homepage">
<form action="http://example.com/contact/" method="post"></form>

The summary counts one blockable reference, two upgrade candidates and one form reference: four occurrences across three rows. It does not mean four unique files or four confirmed network requests. The example demonstrates report grouping, not a live scan or a complete working contact form.

Find every occurrence of a repeated reference in the responsible content or shared component. Correcting only the first displayed line can leave another instance unchanged. Check the actual rendered source text around that line before deciding which CMS field, theme setting or template produces it.

Check base URLs before changing relative paths

The displayed resource URL is resolved against the document's effective base. Without a custom base, relative paths use the final page URL. An HTTP <base href> can instead make a relative reference resolve to HTTP even when the page itself was fetched over HTTPS.

For a fictional page served at https://example.com/guides/setup/, consider this fragment:

<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>

The image resolves to http://static.example.com/assets/logo.png, not to a file under the HTTPS page's directory. A protocol-relative reference such as //static.example.com/assets/logo.png also uses the base's scheme. Removing http: alone therefore does not establish a secure destination.

The HTML base reference explains how the first applicable base controls relative URLs. Inspect the base and the intended asset location together. Changing it can affect other resources, navigation and form destinations; do not remove a deliberate base without reviewing those effects. An explicit, working HTTPS resource address can make the intended replacement clearer.

Replace the insecure source with a working HTTPS destination

Start where the reference is generated. An old image URL may live in an article field, a logo setting or a shared template; an embedded script may come from an integration's supplied code. Correct that source rather than editing generated HTML that the next publication will overwrite. Avoid a blanket replacement of unrelated http:// strings across the site.

Check the proposed HTTPS destination before using it. It should deliver the intended image, script or other resource without an unexpected redirect, access screen or different content. This checker has not performed that request. A change from http://static.example.com/site.js to HTTPS can fail if that host does not serve the same file securely.

If a third-party dependency has no suitable secure version, ask for a supported replacement or decide whether the feature should be removed or replaced. Do not silently substitute an unrelated asset just to clear a finding. For a form, verify the receiving endpoint and expected behavior, not merely its spelling.

A Content Security Policy containing upgrade-insecure-requests can change browser requests while leaving HTTP references in the source. As the directive documentation explains, an unavailable HTTPS resource can fail without falling back to HTTP. This is not proof that every upgraded resource works. Use the HTTP Headers Checker to inspect declared response headers separately; do not replace an existing policy blindly or disable browser protections to hide the problem.

Verify both the published source and browser requests

Keep the original report and intended replacement together before making changes. Download JSON preserves the retained findings and groups; selecting a category changes the table view, not the full report download. There is no CSV export or automatic repair in this tool.

1. Publish the corrected content, setting or template, then check the same HTTPS page again after the updated response is available.
2. Compare the affected URL, element, attribute and occurrence count. A lower total can hide a different remaining reference, so inspect the rows rather than only the summary.
3. Open the page in a browser and review developer-console warnings and network requests. Exercise the relevant image, media or feature; the source report does not run those interactions.
4. Recheck other pages using the same changed template. A repaired homepage does not establish that every product or article has been corrected.

Chrome's security-panel guide explains how non-secure origins lead to the corresponding network requests. Browser evidence can reveal requests created by scripts or styles that this source-only tool does not inspect. It can also show an upgraded or blocked request even when the original source still contains HTTP.

Keep those observations distinct: a corrected source reference and a successful browser request answer different questions. Neither by itself proves that all content, every browser or the entire website is secure.

Understand missing findings and partial coverage

The checker accepts up to 2 MiB of HTML and retains up to 1,000 HTTP references in 200 grouped rows. If a result limit prevents retaining more evidence, coverage becomes partial and the complete reference total is unknown. The summary then describes the retained portion, not every reference in the document. A source that cannot be fetched or exceeds the HTML limit instead leaves the requested check unavailable.

No findings means no supported HTTP references were found in the inspected source scope. It does not cover JavaScript-generated requests, CSS url() values, external stylesheet contents, nested frame documents or every possible resource attribute. It also does not follow resource redirects: an HTTPS asset that later redirects to HTTP is not established by reading its original attribute.

Normal navigation anchors are excluded, including a regular link to an HTTP page. Download behavior and the destination's security need separate review; absence from this table does not approve them. Use the Internal Link Analyzer when your question concerns the page's outgoing links rather than embedded resources.

For a partial report, preserve its scope with the JSON download and investigate remaining source references separately. Removing the displayed rows does not prove that omitted references are fixed. Rerun after changes and retain the earlier report so you can tell a confirmed correction from evidence that was never checked.