The thumbnails that are broken are for the images that are broken. I cannot find anything that can read these thumbnails, including photoshop, online converters or 3rd party plugins. Windows does not natively support heic, but there is a plugin that allows it.
These images are over a year old, so they would have been iOS 17. However thank you for pointing out that ios 18 has HEIC changes. I will investigate that.
Deeper analysis of the photos shows data corruption. I spent a few hours trying to recreate / salvage these photos with help of AI bot. This is what we found:
Problems in the Broken File
- mdat appears as a 1-byte stub, and the real media data is in a misnamed box dat\0.
- HEIC parsers expect a proper mdat box — it stores image binary data.
- The HEIC format is sensitive to box names and order.
Repair Strategy (90% confidence it'll make the image open)
- Rename the dat\0 box to mdat.
- Remove the 1-byte dummy mdat.
- Recalculate box offsets and rebuild the structure.
Rebuilding the box did not succeed, nor did simply copying the header data from a working file to the other. After a few hours we ended up here:
Overall analysis is an export/transport problem:
Likely Cause: File Transfer Truncation or Misinterpretation on Windows
💡 Key Indicators:
- All files have a valid ftyp and sometimes meta.
- Most have a 1-byte mdat, which is nonsensical — mdat should contain all image data.
- Real data exists in a misnamed box (dat\0 instead of mdat).
- File sizes are normal (not 0–10KB), so data was not entirely lost.
- Multiple files share the exact same corruption signature.
Hypothesis (Confidence: 90%):
The HEIC files were likely corrupted during transfer or unpacking from iOS/macOS to Windows, due to:
Transfer Tool Issue:
Software (e.g. iTunes, iCloud for Windows, Explorer import) misparsed or rewrote the HEIC box headers, renaming mdat → dat\0, or inserting a dummy mdat.
- Tools that repackage photos might try to make them compatible with Windows, breaking spec-compliance.
Filesystem Interference:
If transferred via non-native or interrupted USB/SMB/MTP, metadata and chunk alignment might be off.
- Some MTP drivers truncate or shift binary streams.
Misinterpretation of Container Format:
- Apple's HEIC implementation is stricter than many parsers.
- If the HEIC was internally tiled, chunked, or encrypted, and then partially repacked for Windows, the structure may survive, but the offsets and identifiers will be invalid.
Supporting Evidence:
- Multiple images have valid structure but incorrect linking.
- The mdat box being exactly 1 byte in several cases is not coincidental — it's a placeholder.
- Real data is immediately after the dummy mdat, suggesting reassembly was attempted incorrectly.
I want to focus on this:
If the HEIC was internally tiled, chunked, or encrypted, and then partially repacked for Windows, the structure may survive, but the offsets and identifiers will be invalid.
In the past some HEIC files that had been modified had a different naming structrure I think it was like IMG_E1230.heic . Perhaps the "E" stands for edited? There are reports of these photos failing to copy properly to windows. However, it usually wasn't a big deal because the original unedited photo would still be there. I am wondering if apple changed how this works - for example, keeping the edits stored with the photo in the meta data - which then breaks somehow when being transfered.
