Mixed Content Test: Find and Fix HTTP Files on HTTPS Pages

What is mixed content? Upgradable and blockable files explained

A page has mixed content when the main document arrived over HTTPS but at least one file it depends on arrived over HTTP. That request is unencrypted, so an attacker on the network can read or change the file on the way.

The W3C Mixed Content specification splits these files into two groups: upgradable content is requested again over HTTPS and blocked if that fails, while blockable content is refused outright. Google Chrome, Mozilla Firefox and Microsoft Edge apply that split, and Apple Safari is stricter and blocks more. The web.dev guide to mixed content explains the same model.

An upgradable type becomes blockable when its address is a bare IP number instead of a domain name. Older guides say passive and active for the same two groups; this page uses the new names.

Upgradable content (formerly passive)

Images, audio and video cannot rewrite the page, so browsers try the HTTPS version first. With no secure copy, blocked mixed content shows as a broken image.

Blockable content (formerly active)

Scripts, stylesheets, iframes and API calls can change what the page does, so browsers refuse them over HTTP. This group breaks layouts, menus and forms.

A file download linked over HTTP from an HTTPS page is a mixed download, and browsers commonly block it or warn the visitor. If the certificate is your problem, start with our SSL checker and HTTPS test guide instead.

Why mixed content hurts security, trust and SEO

A secure page is only as safe as its weakest file. If one script loads over plain HTTP, anyone between the visitor and your server, such as a person on public Wi-Fi, can read the request or swap the response. A swapped script runs with your page's full rights.

Trust takes the next hit. Depending on the browser, the address bar can show a not secure warning, and blocked insecure content leaves broken images or a checkout button that does nothing.

Search is the part people overstate. Google Search Central's page experience guidance lists secure HTTPS delivery as one consideration, says no single signal decides rankings, and never mentions mixed content, so no penalty is documented. The cost is indirect: blocked CSS or JavaScript breaks the page, and a broken page loses sales. More context is in our write-up on SSL and SEO rankings.

Typical causes are an HTTPS migration that left old URLs in the database, hard-coded URLs in templates, third-party embeds, and proxied apps printing http:// links.

How SEO Site Checker tests mixed content

Our audit loads your URL in a real headless Chromium browser, waits for the page to finish loading and reads the rendered HTML. An address typed without a scheme is audited as https://. Scripts that run before the load event count, but content injected much later can be missed.

The exact rule: The report collects the src of every img, script and iframe tag and the href of every link tag. If any value starts with http://, in upper or lower case, the check fails. If none do, it passes.

What the check reads

Only those four tag and attribute pairs are inspected. Addresses that begin with https://, a protocol-relative // address, a relative path or a data: URI pass. The check keeps a count and the first ten offenders, but the report page does not list them, so after a fail you still have to find them yourself with the methods below.

What pass and fail look like in the report

A pass shows a green tick and a message that the page does not use mixed content. A fail shows a red icon, a message that it does and a red How to Fix button, which opens the short plan repeated in the How to Fix section of this page. There is no amber state.

What it does not catch

A clean result is not a guarantee. The check is stricter than a browser because every link tag counts, even rel canonical or rel preconnect, and our canonical tag check explains why a canonical should be https:// anyway. It is looser too: CSS url() values, srcset, video, audio, source, object, embed and form actions are not read. A page audited over plain http:// that references absolute http:// files fails too, but that signals a missing HTTPS setup, not mixed content, so check the HTTPS setup first.

Run the mixed content test

How to find mixed content on your website

Use these in order, since each is blind somewhere.

1. Run the free report. Treat it as a quick mixed content checker: it shows whether any img, script, link or iframe tag still uses http://.
2. Read the browser console. Open the page over https and check the Chrome DevTools console for a warning that names the insecure resource it requested. The Network tab, filtered by scheme, catches the rest. The Issues panel in DevTools groups mixed content, and Lighthouse reports insecure requests under Uses HTTPS.
3. Search the source. Use view page source and search for http:// inside src, href and url( values, then repeat in your theme files. This misses files added by scripts later. Ignore ordinary a tag links, XML namespace lines and schema.org context lines.
4. Repeat per template. Check a home page, an article and a checkout page, since a clean home page says little about old posts.
5. Scale up with a crawler. A site crawler can export every offending address across hundreds of pages, which beats opening them one at a time.

Mixed Content: The page at 'https://example.com/blog/' was loaded over HTTPS, but requested an insecure script 'http://example.com/js/app.js'. This request has been blocked; the content must be served over HTTPS.

That is a typical Chrome mixed content error for a blocked script. Auto-fixed images and other browsers word it differently, but the offending URL is always named, so search for that.

To collect real visitor reports safely, send a Content-Security-Policy-Report-Only header with a policy such as default-src https: and a report-uri or report-to endpoint. Expect noise from inline scripts and data: URIs, so filter the reports for blocked http: addresses.

How to fix mixed content, step by step

Fix addresses at the source. Safety nets come last, since they hide the problem without changing what is stored.

1. List the offenders. Group every address by where it lives: theme files, database content, plugin settings or third-party embeds.
2. Test each one over HTTPS. Paste the address into a browser with https:// in front. If it loads, change it. If not, host the file yourself, switch provider or remove it.
3. Change it at the source. Edit templates, CMS settings and, for old posts, the database. Use full https:// addresses, not protocol-relative URLs starting with //, which are a legacy workaround.
4. Fix proxied apps. An application behind a load balancer or reverse proxy needs to trust the X-Forwarded-Proto header, or have its base URL set to https. In Laravel, trust the proxy and set APP_URL to the https address.
5. Add the safety net. The Content-Security-Policy directive shown in the code samples below rewrites insecure requests to HTTPS, but it does not edit the saved URL, so a source scan including ours can still flag the page, and a file with no HTTPS copy will fail to load. HSTS is a separate hardening step and does not repair it.
6. Clear caches and re-test. Purge the page cache, CDN and plugin-generated CSS, then run the test again.

Redirecting http:// pages to their https:// twins is a separate job, covered in our guide to http to https redirects. For the full list of elements browsers rewrite or block, see the MDN mixed content reference open in another tab.

How to fix mixed content in WordPress, Shopify, Wix and behind a CDN

The Cloudflare row hides a trap: files requested later by JavaScript or CSS are not rewritten, so the report can turn green while stored URLs stay wrong. The Cloudflare Automatic HTTPS Rewrites documentation lists its limits. Our CDN usage test shows whether a CDN sits in front of your site, and the hosting checker names the provider.

Mixed content examples and copy-paste fixes

The first sample shows wrong and right versions of the tags our report reads.

<!-- Wrong: all three are flagged -->
<img src="http://example.com/img/logo.png" alt="Logo">
<script src="http://example.com/js/app.js"></script>
<link rel="stylesheet" href="http://example.com/css/site.css">

<!-- Right: same files over HTTPS -->
<img src="https://example.com/img/logo.png" alt="Logo">
<script src="https://example.com/js/app.js"></script>
<link rel="stylesheet" href="https://example.com/css/site.css">

The second is the safety net: a header that makes browsers request insecure addresses over HTTPS, first for Apache, then for Nginx. If you already send a Content-Security-Policy header, add this directive to it instead of setting a second header.

# Apache
Header always set Content-Security-Policy "upgrade-insecure-requests"

# Nginx
add_header Content-Security-Policy "upgrade-insecure-requests" always;

The third is the WordPress fix with WP-CLI search-replace: back up, dry run, then run it for real. Skipping guid keeps post identifiers stable. Multisite needs the network flag.

wp db export backup-before-https.sql
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid

Mixed content mistakes and false alarms to watch for

The classic mistake is fixing only the home page, since old posts and footers keep the old scheme. Almost as common is trusting a plugin that rewrites output while the stored URLs stay on http://.

False alarm: A canonical, profile or preconnect link that still says http:// is flagged by our report even though a browser would not load a page file from it. Fix it anyway, because it is a stale URL.

• Old sitemaps and markup. A sitemap or structured data that lists http:// addresses points crawlers at the wrong version. Rebuild it with our XML sitemap generator after the move.
• Vendors with no HTTPS version. Old analytics snippets and ad tags sometimes have no secure address. Replace the vendor rather than live with the mixed content warning.

How to keep mixed content from coming back

• Write full addresses. Use https:// in every template, post and setting from now on.
• Set the site URL everywhere. Point the CMS and app config at https and trust proxy headers.
• Add HSTS carefully. HTTP Strict Transport Security (RFC 6797) is worth enabling only once HTTPS works on every page and subdomain you serve, because browsers remember it for the whole max-age period. Our HSTS check shows what your server sends today.
• Watch in report-only mode. After big changes, run the report-only header described earlier for a week.
• Re-test after changes. Run the report after each theme, plugin or ad update. Use the technical SEO checklist to place this check in a regular routine.