Find mixed content on your HTTPS site

SiteCurl scans your HTTPS pages for files loaded over plain HTTP. This includes images, scripts, CSS files, fonts, iframes, and any other resource referenced in your HTML. When an HTTPS page loads a file over HTTP, browsers call this mixed content.

The check shows which files load over HTTP, on which pages, and what type of resource they are. Active mixed content (scripts and iframes) is more dangerous than passive mixed content (images and fonts), and SiteCurl flags both types.

Modern browsers block active mixed content by default, which means your scripts will silently fail. Passive mixed content may still load but the lock icon disappears, telling visitors the page is not fully secure.

Mixed content is one of the most common side effects of moving a site to HTTPS. The cert is in place, the redirect works, and the site looks fine. But buried in the HTML are links to images, scripts, and fonts that still use http:// URLs.

The browser spots this right away. It sees a secure page trying to load a file that is not secure. What happens next depends on the file type. For scripts and iframes, the browser blocks the file. Your page loads without it. If that script ran your cart, your chat widget, or a key UI piece, it just stops working. No error page. No warning to the user. The feature is gone.

For images and fonts, the browser may still load the file but strips the lock icon from the address bar. Some browsers show 'Not Secure' instead. Visitors see this and assume the whole page is unsafe, even though the page itself loaded over HTTPS.

The hard part is finding every HTTP link. They can hide in your HTML, in CSS files (background images), in your database (old media URLs), in third-party widgets, and in embed codes you pasted years ago. A single HTTP link anywhere on the page is enough to trigger the warning.

This is why scanning every page matters. Your home page may pass, but a blog post from 2022 may still link to an HTTP image. SiteCurl checks every page in your scan so nothing hides.

Mixed content weakens HTTPS. If your page is secure but an image loads over HTTP, the connection is only partly safe. Browsers respond by removing the lock icon or showing a security warning. Visitors see this and question whether your site is safe.

This often shows up after a move to HTTPS. Old links and files still point to HTTP URLs. A redesign from three years ago might have hard-coded image paths that never got updated. One HTTP image can strip the lock icon from a page that is otherwise secure.

There is also a functional risk. Scripts loaded over HTTP are blocked by modern browsers. If your site depends on a script that uses an HTTP URL, that feature breaks silently. No error page. The script just does not load, and whatever it controlled stops working.

Sites that moved from HTTP to HTTPS in the last few years are the most likely to have this issue. The longer a site ran on HTTP, the more old links piled up in templates, database content, and third-party embeds.

Online stores with big product lists are hit hardest. If product images were added before the HTTPS move, they may still use HTTP URLs in the database. That can mean hundreds of product pages with a missing lock icon.

Blogs and content sites with years of posts often have images and embeds from older posts that still point to HTTP. Each post is a source of mixed content you will not find without scanning.

Sites that use third-party widgets (chat tools, review badges, ad scripts) may pick up mixed content from those widgets. If the widget loads a file over HTTP, your page gets the warning.

Step 1: Search your HTML for http:// references. Open your site's source code and search for http://. Each occurrence is a potential mixed content issue. Check if the resource is available over HTTPS by changing http:// to https:// in the URL.

Step 2: Check your CMS site URL setting. In WordPress, go to Settings > General and make sure both 'WordPress Address' and 'Site Address' use https://. In Shopify, HTTPS is automatic. In other CMS platforms, check the base URL setting.

Step 3: Update database content. If your CMS stores content in a database, old posts may contain hard-coded HTTP image URLs. In WordPress, use the Better Search Replace plugin to change http://yoursite.com to https://yoursite.com across all content.

Step 4: Fix CSS and JavaScript files. Check your stylesheets for background-image URLs and font-face src URLs that use HTTP. Check JavaScript files for hard-coded HTTP endpoints.

Step 5: Handle third-party resources. If an external script or image is only available over HTTP, you have two options: host it yourself over HTTPS, or remove it. Most CDNs and image hosts support HTTPS. If a resource does not, it should not be on your page.

Step 6: Use protocol-relative URLs as a last resort. URLs starting with // (no protocol) inherit the page's protocol. This works but is less explicit than https://. Full HTTPS URLs are the preferred approach.

Fixing HTML but missing CSS. Mixed content can come from background-image and font-face lines in your CSS, not just your HTML. Search your style files for http:// too.

Only checking the home page. Mixed content hides in old blog posts, archive pages, and URLs you rarely visit. Your home page may pass, but deeper pages may still fail. Scan all pages, not just the ones you check often.

Bulk find-and-replace without testing. Swapping all http:// to https:// can break things if a file is not served over HTTPS. Check that each URL works with HTTPS before you make the change.

Skipping the browser console. Open your console (F12) on any page. Mixed content warnings show up here before visitors see them. Fix them as they appear.

After making changes, run another SiteCurl scan. The mixed content finding count should drop to zero. For a quick page-level check, open the browser console (F12) and look for 'Mixed Content' warnings in the Console tab.

Check the lock icon in your browser's address bar. If it shows a solid lock with no warnings, the page is fully secure. If it shows 'Not Secure' or a broken lock, mixed content is still present.

For a thorough manual check, open the Network tab in developer tools, reload the page, and filter by 'mixed-content' or look for requests using http://. These show exactly which files are still loading over plain HTTP.

Mixed content is a common leftover from moving to HTTPS. A single HTTP file can strip the lock icon from a secure page. Search your code, CSS, and database for http:// links, switch them to https://, and scan again to make sure none remain.