A RAW file wont open Lightroom for exactly three reasons: the container header is damaged, a metadata block is missing, or the file is truncated. The dialog box says “unsupported or damaged” for all three, which is why most people give up at the point where the diagnosis should start. The distinction matters because two of the three are often recoverable, and one of them is recoverable even when the sensor data is not.
This is a professional’s failure mode, and it deserves a professional’s procedure. Everything below assumes you have already copied the files off the card and are working on duplicates.
Three Reasons a RAW File Will Not Open
The symptom is identical across all three causes, so the diagnosis has to come from file inspection rather than from the error message.
| Cause | What is broken | What you see | Outlook |
|---|---|---|---|
| Header corruption | The first bytes, the file’s signature, are no longer valid | Instant refusal; no thumbnail; the app never gets to the pixel data | Often fixable with a reference file |
| Metadata loss | Maker note, EXIF, or the XMP sidecar relationship is broken | File may preview in some apps and fail in others | Usually fixable, sometimes by stripping metadata |
| Truncation | The file ends before its data does | Partial or no decode; embedded preview sometimes intact | The raw data is partly lost; the preview often survives |
One diagnostic shortcut is worth internalizing before anything else: if the file opens in one application and fails in another, the problem is metadata or catalog state. If it fails everywhere, the container or the data is damaged. The general version of this logic, across photos and videos, is in what to do when recovered files will not open.
Cause One: The Header Is Damaged
Every RAW file begins with a signature, and every converter reads that signature before it does anything else. The common ones are short and specific: CR2 and NEF start with the TIFF magic number 49 49 2A 00, ARW does the same, CR3 uses an ISO base media container beginning with ftyp, DNG is TIFF-based, and RAF begins with an ASCII FUJIFILMCCD-RAW block. The layout differences by brand are collected in RAW file formats by brand.
If the first sixteen bytes do not parse, the software stops. It never reads the image data, which means the pixels may be perfectly intact while the file is unopenable. That is the whole reason this cause is worth attempting rather than discarding.
The fix is to supply a valid header from a healthy file of the same camera model, shot with the same settings. Open both files in a hex editor, copy the header region from the good file, and write it over the damaged region in the copy. A few rules make the difference between a repair and a second broken file:
- Match the model, not just the brand. Header fields include sensor dimensions and offsets that vary between bodies, and an A7 IV header will not describe an A7 III file.
- Match the compression setting. Uncompressed, lossless compressed, and compressed RAW variants have different structural expectations.
- Work on a duplicate. A failed splice can leave a partly readable file entirely unreadable.
Some repair utilities automate exactly this by asking you to nominate a reference file. Nothing about the technique is exotic; it is the same logic used to repair a video missing its index, which is covered in the notes on rebuilding a missing moov atom.
Cause Two: A Metadata Block or Sidecar Problem
RAW files carry several layers of metadata, and the structures involved — EXIF, maker notes, and the XMP sidecar that Lightroom writes alongside the file — are separate from the image data. That separation produces the most misleading failure in the group.
Lightroom’s catalog is a database, and it tracks the expected relationship between a file and its sidecar. A file whose sidecar was lost in the same accident, or whose maker note no longer parses, can be rejected by Lightroom while opening normally in a tool that reads the raw data directly. Capture One, darktable, RawTherapee, Photoshop’s Camera Raw, and FastRawViewer all decode differently, and their disagreement is diagnostic information rather than a curiosity. The metadata layer itself is covered in how camera metadata works.
Three fixes are worth trying in this order:
- Test outside Lightroom first. If the file opens elsewhere, you are dealing with a catalog or sidecar issue rather than file damage. Removing and reimporting the file, or resetting its sidecar, often resolves it.
- Repair the metadata with ExifTool. Copy tags from a healthy reference file with
-tagsfromfile, or rebuild the missing EXIF block. This is the standard route and it preserves the image data untouched. - Strip metadata entirely with
exiftool -all=on a copy. Counterintuitively, deleting metadata can make a file open, because the converter is then free to make its own assumptions instead of failing on a malformed block. You lose capture data, not pixels.
The third option is the one people resist, and it is often the one that works.
Cause Three: The File Is Truncated
Truncation is the case that produces partial recovery, and it has a specific fingerprint. The file is smaller than the camera would normally produce for that model, the last portion of the image may render with a hard edge or not at all, and a thumbnail sometimes still displays.
Truncation comes from an interrupted transfer or a card that stopped accepting writes partway through a file. When a card is failing, the copy utility may report success having copied only part of the file, which is why verifying transferred and recovered files is worth the time on any suspect job.
The recovery path is the embedded preview, and it is better than most people expect. Nearly every RAW file contains at least one JPEG rendition written by the camera: a thumbnail, and in most systems a full-resolution preview for the rear screen and for quick rendering. The exact placement is a brand characteristic, and one of them is unusually helpful — a RAF file from Fujifilm is a container that leads with a complete JPEG, so a truncated RAF frequently yields a usable image from its first segment.
The practical lesson is simple. Before treating a truncated RAW as lost, extract the embedded JPEG. The full procedure is in extracting a JPEG preview from a RAW file, and it routinely produces a deliverable image where a converter produces nothing.
Tools That Work, and What Each One Cannot Do
| Tool | What it can do | Where it stops |
|---|---|---|
| ExifTool | Read and rewrite EXIF, maker notes, and sidecars; extract embedded previews; copy tags from a reference file | Does not repair structural container damage or raw sensor data |
| dcraw, LibRaw, RawTherapee, darktable | Decode tolerantly; some accept truncated or structurally odd files | May render a partial image or crash on badly damaged containers |
| Brand software (DPP, NX Studio, Imaging Edge, X Raw Studio) | Often more forgiving of its own brand’s files and quirks | Refuses files from other brands; no structural repair |
| Lightroom and Camera Raw | Nothing. They validate strictly by design | They are the messenger, not the problem |
| Commercial RAW repair utilities | Automate header splicing and metadata rebuilding | Cost money; results vary with damage type |
The important entry is the fourth row. Treating Lightroom’s refusal as evidence of file damage is the most common wasted hour in this workflow, because the same file may open elsewhere with no repair at all.
The Order to Work In
Following a fixed order avoids the two typical mistakes: repairing a file that did not need it, and stripping metadata that could have been preserved.
- Copy the files and work on the copies. Never let a repair tool write to your only version of a file you cannot reshoot.
- Inspect the structure. A read-only pass with ExifTool tells you whether the container parses, whether the preview exists, and what the file claims it is.
- Try a second decoder. Capture One, darktable, or the brand’s own software. Disagreement between tools points to metadata; agreement points to the container.
- Extract the embedded preview. It costs a minute, and it converts a dead file into a deliverable image where the raw data is gone.
- Repair the metadata with ExifTool, copying tags from a healthy reference file.
- Splice a header from a same-model reference file, on a copy.
- Escalate to a commercial repair tool only for files you cannot lose, and only after the cheap options are exhausted.
If the file came off a card that is still misbehaving, the underlying source matters more than the repair. Files that will not open after a recovery scan often indicate a scanning problem rather than damage, and that is the subject of RAW photo recovery. For files that open but render with bands or blocks, the issue is missing data rather than structure, which is a different conversation covered in repairing photos with gray blocks.
If you are on Windows and the card that held these files is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive. Data that has not been overwritten comes back in full; data that has been overwritten cannot be recovered by any tool, and no repair utility can invent pixels that are no longer on the card.
Frequently Asked Questions
Why does Lightroom say my RAW file is damaged when other apps open it?
Because Lightroom validates the file system relationship, the sidecar, and the metadata block before it decodes anything. A missing or malformed block is enough for a refusal. If Capture One or darktable opens the same file, treat it as a metadata or catalog problem and repair or reset the sidecar rather than the file.
Can a truncated RAW file still produce a usable image?
Frequently, yes, through the embedded JPEG preview. Most cameras write a full-resolution rendition into the RAW container, and with some brands, including Fujifilm, the preview sits at the front of the file. Extract it before writing the file off; it is not a RAW, but it is a photograph you can deliver.
Is stripping all metadata safe?
It is safe for the image data and lossy for information. Running exiftool -all= on a copy removes EXIF, maker notes, and capture settings, and it can make a file open when a malformed block was blocking the decode. Do it on a duplicate, and keep the original until the stripped version is confirmed good.
What is the best tool to repair a corrupted RAW file?
There is no single answer, because the three causes need three different tools. ExifTool covers metadata and preview extraction, a hex editor with a same-model reference file covers header damage, and a tolerant decoder such as LibRaw or darktable covers partial data. No consumer tool reconstructs raw sensor data that is no longer in the file.