A secure page references images or media at http:// addresses

Why it matters

Images, audio and video cannot change the rest of the page, so browsers commonly upgrade them and request them over HTTPS; images chosen through srcset or <picture> are blocked instead. Google's list of insecure dependencies that work against its HTTPS preference leaves images out.

What to do

1. Look at the finding: it lists up to ten http:// references with their kind, such as img or video, and a count of the rest.
2. Open each file at its https:// address to confirm it is served there, then change the address in the page, the media settings of your website editor or the template.
3. If many old posts hold http:// addresses of your own site, a search-and-replace tool can change them together; make a backup first.

When to leave it as it is: if every such file loads over HTTPS in current browsers, the page works as it is; the finding stays open until the addresses change, the page sends upgrade-insecure-requests, or it permanently redirects within your site.

What we read

We read each crawled page that ends on an https:// address and answers 200 with complete HTML, up to 2 MiB, without running JavaScript. We look at <img src> and <img srcset>, <audio src>, <video src>, and <source src> or <source srcset> inside <audio>, <video> or <picture>, skipping those inside <noscript> or <template>.

A page is reported when at least one of these addresses is written with http://; relative and // addresses are not. A <source srcset> is read only when its first address uses http://; its other http:// addresses are then listed too, and otherwise they are missed. A page whose Content-Security-Policy header or meta tag includes upgrade-insecure-requests is not reported, and the files are not fetched.

Example & evidence

Illustrative example — one page, not a live audit.

https://bakery.example/menu/ answers 200 and sends no Content-Security-Policy. Its HTML contains:

<img src="http://bakery.example/img/croissant.jpg" alt="Croissant">

The image's address uses http://, so the page is kept for review: img: http://bakery.example/img/croissant.jpg.

A possible correction: src="https://bakery.example/img/croissant.jpg", or the relative src="/img/croissant.jpg".

Confirm & check again

Check for yourself: open the page in Chrome with developer tools and look in the Console for "Mixed Content" messages, and view the source and search for http:// in src and srcset attributes.

Check again: Full audit — run a new audit of the site. The finding closes when the page is crawled again as a complete HTML page with no such http:// reference, or with upgrade-insecure-requests in its policy, or now permanently redirects within your site. A page that is only a frame for scripts, or is not reached by the crawl, cannot be confirmed.

Limits & sources

The check does not show whether a browser upgraded or blocked a file, or whether an https:// copy exists. CSS background images, files added by JavaScript, lazy-loading attributes such as data-src, <video poster> and <track> are not read. Images chosen through srcset or <picture> are kept for review at the same level as the others, although browsers block them.

Confidence: High because each address is read exactly as written in the HTML.

Sources

• MDN, Mixed content — lists images, audio and video as upgradable content that browsers should request over HTTPS, and images set through srcset or <picture> as blockable. Checked 25 September 2026.
• Google, How to specify a canonical URL with rel="canonical" and other methods — lists insecure dependencies on an HTTPS page as a signal against Google's HTTPS preference, with images excluded. Checked 25 September 2026.

Editorial review: 29 September 2026

Related

• A secure page references active content at http:// addresses — scripts, stylesheets, frames and embedded objects at http:// addresses, which browsers block.