An image can disappear after you enable HTTPS because the page itself loads securely while that image still uses an insecure http:// URL. Blogger calls this mixed content. The same issue can affect videos, stylesheets, and scripts, so a missing image may point to a wider resource-loading problem on that page.
Start with the exact page where the image is missing. Open it through HTTPS, inspect the browser’s JavaScript Console, and write down both the page URL and every insecure resource URL named in a mixed-content message. Google’s Blogger mixed-content guidance says to check pages separately: an error appears for the page being viewed, not for the whole blog at once.
That detail saves time. One failing post calls for a post-level check. The same resource error across several pages points first toward the theme. Gadgets come after those checks if the errors remain.
What mixed content means on a Blogger page
A page can arrive over HTTPS while requesting a later file over HTTP. Blogger lists images, videos, stylesheets, and scripts among the resources that may trigger mixed-content errors. The browser messages can identify an insecure image URL or an insecure script URL.
HTTPS availability and the resources inside a page are separate things. Blogger’s settings documentation says Blogspot addresses are always HTTPS, while custom domains have HTTPS availability and HTTPS redirect settings. HTTPS redirect sends visitors to the secure version of the blog address. A redirect setting does not identify or replace an old HTTP image, script, or stylesheet embedded in a post, theme, or gadget.
For that reason, begin with the resource named by the browser instead of editing every occurrence of http:// across the blog. Google’s instructions limit the replacement check to HTTP URLs inside relevant HTML tag attributes: img, video, audio, script, and link. A URL outside those attributes may need a different review.
Record the error before changing anything
Visit the affected page using HTTPS and open the browser’s JavaScript Console. Look for mixed-content messages, then capture these items in a short note:
| Record | Why it matters |
|---|---|
| The HTTPS page address | It identifies the page currently being tested. |
| Each insecure resource URL | It gives the exact file or endpoint the browser reported. |
| The resource type | The message can refer to an image, script, or another resource. |
| Other pages with the same error | Repeated errors are a clue that the source may be shared. |
Check each affected page individually. A homepage may load without a warning while an older post still requests an HTTP image. The reverse can happen too: a shared theme resource may affect many posts even when their own HTML has no insecure URL.
The goal is a small, usable list. You need the page address, the resource address, and a record of whether that resource appears on one page or across several pages.
When the error appears on one post or page
Google says an error limited to one page likely comes from that post or page’s source. In the Blogger dashboard, open Posts or Pages, find the affected item, and choose Edit. Switch the editor to HTML.
Search for http://. Do not rely only on the visible editor view. The source may contain an image URL that is not obvious in the rendered text.
Inspect any result inside an img, video, audio, script, or link tag attribute. An image entry might contain an HTTP address in its src attribute. A stylesheet or script can use an HTTP address in an attribute of its own. Compare that address with the one written down from the browser error.
Before changing an HTTP address to HTTPS, test the proposed HTTPS URL in a separate browser window. Google’s documented check is simple: the HTTP and HTTPS versions should give the same result. If the HTTPS version does not work, do not assume that swapping the protocol will repair the resource. The file may not be available through HTTPS.
When the HTTPS address works, update the relevant URL in the HTML editor. Save, update, or publish the post or page. Blogger may show editor errors and refuse to save when the content has errors. Google also notes that dismissing an error can allow a save while leaving the underlying issue in place; refreshing can show the errors again.
Return to the published page over HTTPS and inspect it again. The edit is complete only after the previous mixed-content message has gone from that page.
When the error appears on several pages
The same mixed-content error on multiple pages likely comes from a shared source. Google directs Blogger users to inspect the theme first.
Open Theme in the Blogger dashboard and select Edit HTML. Search the theme content for http://. As with a post, focus on URLs used in img, video, audio, script, or link tag attributes. Match any candidate to the insecure URL reported in the Console.
Test the HTTPS version in a separate window before editing the theme. A working HTTPS version can replace the HTTP address. Save the theme, then revisit every page that showed the error. One shared resource can appear in a header, sidebar, footer, or other theme area, so testing only the homepage leaves gaps.
The one-page versus several-pages distinction is a diagnostic clue. It narrows the next place to inspect; it does not prove the source without checking the reported URL in the relevant HTML.
Check gadgets if the theme still looks clean
Google lists gadget source as another possible cause of mixed content. If the error remains after checking the affected post or page and the theme, review non-Google gadgets.
Google’s documented isolation method is to remove non-Google gadgets, check the blog again for mixed-content errors, then add gadgets back one at a time. After each addition, revisit the affected page or pages and inspect the Console. A new error after one gadget returns identifies the gadget as the likely source.
If the gadget exposes its markup or source, inspect it for the insecure URL. If its source cannot be checked or the gadget continues to request HTTP content, removing it is one of Google’s stated options.
This sequence matters because a gadget can appear across much of a blog. Editing an individual post cannot repair a resource that the gadget injects into the page.
Verify the repair page by page
After every save, revisit the page through HTTPS and inspect the Console for remaining mixed-content errors. Repeat this page by page, because Blogger’s guidance says errors show for the current page only.
Keep the earlier record until all affected URLs have been rechecked. If a different insecure resource appears after the first repair, add it to the list and trace its location using the same pattern:
- Record the page and reported insecure URL.
- Decide whether the error is isolated or repeated across pages.
- Inspect the post or page, then the theme for repeated errors.
- Isolate gadgets when errors remain.
- Confirm that a replacement URL actually works over HTTPS.
- Save and revisit the affected page.
A blog can use HTTPS correctly while one old image URL still loads through HTTP. The fix is precise: find the reported resource, locate its source, verify an HTTPS version, save the appropriate Blogger item, and check the affected page again.
Which HTTPS page first showed the missing image? Does the Console name the same insecure URL on another page?
