Open your deck, find a red X where an image should be, and you are looking at one of the most discouraging bugs in modern Office. The honest answer most articles refuse to give you: in the majority of cases, that image is gone. Not hidden, not corrupted-but-recoverable, not waiting behind a setting. Gone. The file no longer contains the picture data, only a reference to a picture part that no longer exists inside the .pptx archive.

This piece explains what the red X actually represents, which versions of it you might see, the small number of cases where recovery is genuinely possible, and the prevention rules that matter. Most of the “fixes” circulating on the internet for this error don’t work because they can’t work — the bytes have already been lost.

What the red X actually represents

A .pptx file is a ZIP archive. Inside that archive, slides live in /ppt/slides/, images live in /ppt/media/, and every reference between them is recorded in relationship files (the .rels files) using a relationship ID like rId2, rId3, rld8, and so on. When you place an image on a slide, PowerPoint writes the image bytes to the media folder, gives that part a relationship ID, and records the link in the slide’s relationship file.

The red X appears when the slide’s relationship file still points to a relationship ID — but the image part it should point to is missing from the archive. PowerPoint dutifully renders the picture frame at the correct size and position, then displays a red X because there is nothing to draw inside it.

You will see this error in three slightly different forms depending on PowerPoint version and platform:

  • A plain red X with no other text — the most common form on Windows.
  • “This image cannot currently be displayed” — a slightly older variant, also seen in Word and Outlook.
  • “The image part with relationship ID rId2 was not found in the file” — the explicit error, sometimes appearing as rId3, rId4, rId8, or any other number. On Mac PowerPoint the spelling is occasionally rld2 due to a font rendering quirk that turns the capital I into a lowercase l.

All three messages mean the same thing: the picture part is gone from the file. The exact wording variation is one of several dozen image-related dialog strings the Microsoft apps produce, and which one you see depends largely on which version of PowerPoint hit the broken relationship first.

The causes — and why “fixes” don’t fix it

This bug is older than people realise. Microsoft acknowledged it during the PowerPoint 2013 era, claimed fixes in subsequent updates, and the fixes mostly held — except the underlying behaviour can still be triggered by specific workflows that have never gone away.

The reliable triggers are:

  • Opening or saving the .pptx directly from a USB flash drive, pen drive, or thumb drive. This is the single most common cause. PowerPoint’s save behaviour assumes a stable filesystem, and removable media occasionally fails to flush writes correctly. The next time you open the file, the relationship file is intact but parts of the media folder are missing.
  • Editing the .pptx from a mounted network drive — AFP, NFS, or SMB shares on macOS specifically. Mac PowerPoint is unusually sensitive to this. Microsoft’s own guidance has, for years, told Mac users to copy files locally before editing.
  • Cloud sync clients interfering during save. Dropbox, OneDrive, Google Drive, iCloud — any client that watches the file for changes and uploads incrementally can occasionally race with PowerPoint’s save process. The file is uploaded mid-save, with some parts written and others not. When the next download or open happens, the archive is internally inconsistent.
  • Specific copy-and-paste sequences — particularly copying graph or chart objects from third-party tools (Prism, certain statistical packages) and pasting them as pictures into PowerPoint. The paste sometimes writes a relationship without writing the underlying media part.
  • Force-killing PowerPoint mid-save, including through Task Manager, a power loss, or a system crash during a save operation.

What these triggers have in common is that the .pptx file ended up internally inconsistent — relationship references existed in the slide XML, but the image data they pointed to was either never written, was overwritten during the next save, or was lost during a sync conflict resolution.

The fixes you will see recommended on Reddit, Spiceworks, and ten-year-old MVP blogs include “save as a new file,” “check for updates,” “remove and reinsert images,” and “run a Quick Repair on Office.” None of these recovers a missing image part. They can prevent the error from happening again. They cannot bring back data that no longer exists in the archive.

When the image is actually recoverable

There is a narrow set of cases where you can get something back.

The image was part of the slide master or template, not your slide content. If the red X appears on multiple slides in the same position and that position corresponds to a logo or template element, the image is referenced from the master slide. You can reimport the master from the original template, and every red X driven by that master image will resolve. This is the easy case — a fix that genuinely works, but only for template-level images.

You have a recent backup, a OneDrive version history, or a SharePoint check-in history. Open File History or the cloud’s version history. Find a version from before the corruption appeared. Open that version. If the images render correctly, you have just recovered them. Save a copy with a different name immediately, because reopening the broken file from the same location may re-corrupt it.

Auto-recovery files still exist. Check %appdata%\Microsoft\PowerPoint\ on Windows for AutoRecover files from the session before the corruption. PowerPoint normally cleans these up after a clean exit, but if the corruption coincided with an abnormal exit, the files may still be there.

Manual extraction from the ZIP archive. If you can find any prior copy of the file — even a slightly older version emailed to a colleague — rename it from .pptx to .zip, open it with any ZIP utility, and look in the /ppt/media/ folder. The images are stored as ordinary JPG, PNG, EMF, or other image files with names like image1.png, image2.jpg. You can copy them out and reinsert them into a working file. This won’t help if the only file you have is the corrupted one (because by definition the images are missing from its media folder), but it works on any earlier copy that still has the pictures intact.

For everything else — and “everything else” is most cases — you are going to have to re-insert the images. There is no software, no command, no setting, no service that recovers an image part that is not in the archive. The bytes do not exist.

Why this isn’t the same as “images disappeared after save”

The red X is often confused with the closely related — and more recoverable — failure where images appear to vanish entirely from a presentation. That issue, covered in detail in the recovery and prevention guide for PowerPoint images disappearing after save, usually has a different root cause: the image references themselves have been stripped from the slide XML, often as a result of cloud-save behaviour with linked images. Recovery is usually possible because the media folder is still populated.

The red X is the opposite condition: the references are still in the slide XML, but the media folder is missing the corresponding files. Worse luck, and harder to recover from. If you see red X placeholders rather than empty slides, you are in the harder of the two failure modes.

The distinction between embedded and linked images in PowerPoint matters here too. Embedded images become part of the .pptx archive and are subject to the corruption failure mode described above. Linked images live outside the file and produce a different broken-link symbol when the link is severed. They are not subject to this particular relationship-ID failure, which is one of the underappreciated reasons embedded images, despite the file-size cost, are the more robust choice for most workflows.

Prevention rules that actually matter

The good news, such as it is: this is largely preventable.

  • Never edit a .pptx file directly from a USB drive. Copy it to your local desktop, work on it there, save it, and copy the finished file back. The two extra clicks are insurance against complete image loss.
  • Don’t edit .pptx files on mounted network shares from macOS. The same rule: copy locally, edit, copy back. Windows is more tolerant of this but not entirely safe either.
  • Keep cloud sync clients out of the active editing path. If you use OneDrive, Dropbox, or similar, save your working copy to a non-synced folder during the editing session. When you finish, save back to the synced folder. This eliminates the race condition between PowerPoint’s save and the cloud client’s upload.
  • Don’t paste-as-picture from third-party scientific or statistical software when you can avoid it. Save the chart as a PNG or PDF and insert it normally instead. This single change eliminates a surprisingly common failure path that affects researchers and analysts disproportionately.
  • Keep version history turned on for any .pptx file that matters. OneDrive, SharePoint, and Google Drive all retain previous versions. The cost is zero. The recovery value when this happens is enormous.

The red X is genuinely one of PowerPoint’s worst failure modes because the data is irrecoverable from the file itself once it occurs. Microsoft has known about it for over a decade and the architectural choice — relationship IDs decoupled from media parts inside the archive — that makes it possible has never been revisited. The only defence is workflow discipline. None of the suggested fixes will recover lost image bytes, because no software can.