Every RAW file from a digital camera contains at least one complete JPEG, and on most modern bodies it is a full-resolution one. When the RAW data itself is damaged beyond repair, that embedded JPEG is frequently untouched, and it is the difference between delivering a photograph and delivering an apology. The task is to extract jpeg from raw file data that your editor refuses to open at all.
The technique is standard practice in professional recovery, not a hobbyist trick, and everything below runs from the command line with free, well-maintained tools. Copy the damaged file somewhere safe and work only on the copy: every command here should run against a duplicate, never the original.
Why there is a JPEG inside a RAW file in the first place
A RAW file is a container, not a picture. Structurally it is a TIFF variant: a header pointing to a directory of image file directories, each holding tagged metadata, followed by the sensor data and, almost always, one or more embedded JPEGs.
Cameras embed those JPEGs for practical reasons. The rear screen needs something to display instantly, and demosaicing a 45 MP readout for every frame the photographer wants to check is far too slow. Camera makers also include it because a great deal of third-party software can read a JPEG and cannot read sensor data, so the preview is a compatibility floor. The difference between RAW, JPEG, and HEIF explains how the container decisions differ across formats.
What matters here is that the JPEG sits in the file as a self-contained, fully indexed image that does not depend on the RAW data being readable. If the container header is intact, the preview is reachable, and even when the header is damaged the bytes are often still findable, because a JPEG announces itself with a fixed three-byte signature.
When extraction is worth trying, and when it is not
| Symptom | Is a preview likely present? | What you can expect |
|---|---|---|
| RAW opens in no editor, errors on load | Very likely | Full-size JPEG, if the file is not truncated at the front |
| File truncated by a failed copy | Likely, if the cut is at the end | The preview, sometimes partly cut |
| First clusters overwritten by new files | Unlikely | The preview lives near the start and shares their fate |
| File is zero bytes | No | Nothing to extract; the scan failed, not the file |
| Camera shows the thumbnail, Lightroom shows an error | Yes | Full-size preview, plus the camera’s preview cache |
| RAW converted to DNG by a third-party tool | Yes, usually | DNG requires a full-size preview by specification |
The pattern is about position, not size. RAW data is written first and the preview follows, so a file damaged in the middle or at the end usually still has a readable preview, while a file whose opening kilobytes were overwritten has nothing. Truncation is the most common real-world case, and it is where extraction succeeds most often.
Extracting with ExifTool
ExifTool reads the tag directory and writes any embedded image to disk. It supports every current RAW format including the HEIF-based ones older tools cannot parse, which makes it the first tool to try.
The recommended move is to dump everything the file contains without knowing the tag names in advance. ExifTool’s -w option with -b writes each binary tag to its own file:
“ exiftool -a -b -W %d%f_%t%-c.%s -EmbeddedImage -PreviewImage -JpgFromRaw -OtherImage -ThumbnailImage DSC01234.NEF “
That produces files named after the tag that carried them, so DSC01234_JpgFromRaw.jpg and DSC01234_ThumbnailImage.jpg appear side by side. Run it on the whole folder if you have several damaged files.
If you only want the largest preview, EmbeddedImage is the tag ExifTool uses for the most complete embedded image:
“ exiftool -b -EmbeddedImage DSC01234.NEF > preview.jpg “
That last form carries a Windows trap worth knowing about. PowerShell’s > redirection does not write raw bytes; older versions encode output as UTF-16, which silently corrupts the JPEG. Either use the -W form above, which lets ExifTool write the file itself, or run the redirecting command in cmd.exe. A preview that will not open in any viewer after an extraction is very often a redirection casualty rather than a damaged file.
Check what you got before you celebrate, because exiftool preview.jpg reports dimensions, compression, and quality settings. A 160×120 image means you extracted the thumbnail and should re-run with the -W form to collect the rest.
Extracting with dcraw and LibRaw
Before ExifTool, dcraw was the standard answer, and it still has the shortest syntax for this job:
“ dcraw -e DSC01234.CR2 “
The -e flag tells dcraw to skip conversion entirely and write the embedded preview as a sidecar file next to the input, using the original base name with a .thumb.jpg extension. If the embedded preview is not a JPEG, dcraw writes a PPM instead.
Two limitations matter. dcraw is unmaintained and predates CR3, HEIF-based containers, and most recent bodies, and on a modern file it will simply refuse. Its maintained descendant, LibRaw, ships command-line tools such as dcraw_emu that accept the same flags with current format support. dcraw also chooses the preview it prefers rather than the largest one available, so verify dimensions before assuming you have the biggest.
A third option is not a command-line tool at all. Adobe’s DNG Converter sometimes produces a valid DNG even when every editor rejects the original, and a spec-compliant DNG always carries a full-size JPEG preview. It is slower and less transparent than ExifTool, but on stubborn Canon and Nikon files it occasionally succeeds where tag parsing fails.
Carving the JPEG by hand when the tags are gone
If the container header is too damaged for any tag reader, the preview can still be found by signature. A JPEG starts with FF D8 FF and ends with FF D9, and those byte sequences are as close to unique as anything in a file this size.
“ python -c "d=open('DSC01234.NEF','rb').read(); print(d.find(b'\xff\xd8\xff'), d.rfind(b'\xff\xd9'), len(d))" “
That prints the offset of the first JPEG start, the last JPEG end, and the file size. To write the image out:
“ python -c "d=open('DSC01234.NEF','rb').read(); s=d.find(b'\xff\xd8\xff'); e=d.rfind(b'\xff\xd9'); open('carved.jpg','wb').write(d[s:e+2])" “
Large files often contain more than one JPEG, and rfind will cheerfully splice two of them together into something no decoder accepts. If the carved file fails to open, search for every start offset and extract each candidate separately. Signature carvers such as binwalk automate exactly this, and binwalk -e DSC01234.NEF is a reasonable shortcut when you would rather not script it.
Here is the counterintuitive part of working this way: a truncated JPEG still renders. JPEG is written top to bottom and decoded the same way, so a decoder that runs out of data mid-image simply stops and displays everything it decoded. A preview missing its final few percent yields a picture with a gray strip or a slightly cut edge, not a broken file. That is why carving is worth attempting even when the bytes after the preview are obviously gone.
What the preview gives you, and what it permanently takes away
The preview is not a low-quality copy of the RAW. It is a different rendering of the same scene, produced by the camera’s own JPEG engine with the picture style, white balance, sharpening, and noise reduction you shot with already applied. That cuts both ways: it can look better than a flat, unedited conversion of a recovered RAW, and you cannot change any of those decisions afterward.
The limits are firm. There is no highlight recovery, because the preview is already tone-mapped and clipped. There is no white balance latitude, because it is baked in. There is no bit depth to grade with, since the preview is 8-bit. If the frame was a once-in-a-lifetime exposure and the composition is what matters, the preview is a genuine deliverable; if the job required a graded RAW, it is a placeholder.
It is still worth going back to the original first. Extraction is what you do when the container is unreadable, not instead of trying to read it. The RAW photo recovery workflow covers what a scan can reassemble from a card, and the repair path for RAW files that open in no editor handles container and metadata damage that extraction cannot fix. Both come before the carve, because both preserve the option of a real RAW. The general repair order for recovered files is worth reading if you recovered a whole folder rather than a single frame.
If you are on Windows and the card is still detected by a computer, a purpose-built tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos, and it can re-encode recovered files that will not open. The boundary is the same for extraction as for scanning: data that has not been overwritten can be recovered in full, a recovered file that will not open can often be repaired or re-encoded, and data that has been overwritten is gone. Stop writing to the card, and save everything you recover to a different drive.
Putting the extracted image back into a deliverable state
A bare JPEG pulled out of a container usually has no EXIF, no capture time, and no location, because those tags live in the container you just bypassed. That is fixable, and it matters if anyone downstream sorts by date or needs the shooting data.
“ exiftool -TagsFromFile DSC01234.NEF -EXIF:all -Orientation -GPS:all -DateTimeOriginal carved.jpg “
If the original is too damaged to read tags at all, copy them from the nearest intact frame of the same shoot and correct the capture time afterward. The metadata rebuild guide covers the tags worth restoring and the ones best left blank rather than guessed. For consistency across a set, note that RAW container layouts differ by brand, which is why the extraction tag names are not the same everywhere and why the dump-all command is the reliable starting point.
Frequently Asked Questions
Is the embedded preview the same quality as a normal JPEG from my camera?
Usually yes. On most bodies the full-size preview is encoded with the same JPEG settings the camera would use for a JPEG capture, at the same pixel dimensions. What you lose is the metadata wrapper and the ability to change any processing decision afterward.
Why did ExifTool give me a tiny image instead of the full-size preview?
You extracted the thumbnail. Most RAW files contain both, and ThumbnailImage is only a few kilobytes. Extract all embedded images at once with the -W form of the command and compare dimensions before choosing which to keep.
Can I re-edit an extracted preview in Lightroom?
You can edit it, but you are editing an 8-bit JPEG rather than a RAW. White balance, exposure, and highlight recovery have almost no headroom because the camera already applied and clipped them. Treat it as a finished file needing light correction, not a negative.
Why does my carved JPEG have a gray strip at the bottom?
The file was truncated before the JPEG data ended, and the decoder rendered every scan line it received before stopping. The gray area corresponds to image rows that were never written, and no tool can reconstruct them because those pixels do not exist anywhere on the card.