Restore photo metadata before you deliver anything, because the photographs will come back looking fine and sorting wrong. Recovered files usually carry their image data intact and their metadata block missing, which means a shoot of 800 frames lands in your catalog with no capture time, no camera model, no lens, and no rights information — all stamped with the date you ran the recovery. Sorting by date puts the entire shoot at the bottom of the library, and a client delivery without creator fields looks unprofessional even when the pictures are perfect.
The useful news is that metadata splits cleanly into two groups. Capture time and rights information are reconstructions you can perform accurately and at scale. GPS coordinates and the original exposure settings are not recoverable from the image alone, and no tool can invent them. This page covers which is which, and the ExifTool procedure that does the rebuild.
Why recovered photos arrive without metadata
A photograph on a card is not one blob of data. It is a JPEG or RAW wrapper whose beginning contains a header, an EXIF (Exchangeable Image File Format) block, a thumbnail, and then the compressed image data. The metadata lives in a small contiguous region near the start of the file.
That geography matters. A carving or signature-based recovery tool finds images by scanning for the start-of-image marker — FF D8 FF for JPEG — and then reading forward to the end marker, reconstructing the file from the compressed data. If the first clusters of the file were reused or damaged, the tool recovers the picture perfectly while the EXIF block is absent or truncated. The photograph is not damaged; the label is.
A second effect compounds it. The file modification timestamp you see in your browser is set by the recovery process, not preserved from the card, so every recovered file appears to have been taken at the same second.
The structure of a camera file and the fields it normally carries are covered in more detail in the explanation of camera metadata and EXIF.
What is gone for good
Three categories of metadata cannot be reconstructed from a recovered image.
GPS coordinates. Position is recorded by a receiver at the moment of capture and is not derivable from pixels. Unless a track log or GPX file exists from the same shoot, the location is permanently unknown.
Exposure settings. Shutter speed, aperture, ISO, focal length, and metering mode were hardware states at the instant of exposure. There is no reliable way to extract them from a decoded image, though they can sometimes be estimated from a sibling frame captured in the same burst. Where a sibling RAW survived intact, the notes on RAW photo recovery cover what can still be read out of it.
As-shot white balance and camera profile. These are the values the camera used to render the frame. A recovered RAW can still be developed, but the starting point has to be chosen manually or taken from a sibling file.
One qualification matters: GPS is unrecoverable from the image but recoverable from a time-matched track log. With a GPX recording and reconstructed capture times, ExifTool can write interpolated coordinates back into the files — the single best reason to fix timestamps first.
What can be rebuilt, and how accurately
| Field | Rebuild method | Accuracy of the result |
|---|---|---|
DateTimeOriginal | Interpolation across the filename sequence within a known shoot window | Good to within a few minutes |
CreateDate, ModifyDate | Same interpolation, or a single value for the whole shoot | Same as above |
| Filesystem modification time | Written explicitly to match the capture time | Exact |
Artist, Copyright | Batch write from a template | Exact: it is your information |
XMP-dc:Creator, XMP-dc:Rights | Batch write from a template | Exact |
Keywords, XMP-dc:Subject | Batch write by folder, shoot, or subject | Exact, being your own classification |
GPSLatitude, GPSLongitude | Time-matched GPX track log | Accurate to the GPS fix, if the track exists |
| Shutter, aperture, ISO | Estimated from a sibling frame in the same burst | Approximate at best |
| White balance, camera profile | Taken from a sibling file or chosen manually | A substitute, not a restoration |
| Lens and body identifiers | Set manually if the camera is known | Exact if the body is known, otherwise guessed |
The table’s first three rows deserve emphasis, because they are where most of the practical value sits. Capture time is the field that drives library sorting, culling, and delivery naming, and it is usually reconstructable to within a few minutes — close enough for every practical purpose.
Reconstructing capture time from filenames and folder names
Camera filenames are sequential, and that sequence is the key to rebuilding time. A shoot that ran from 09:14 to 11:02 and produced files numbered IMG_4101 through IMG_4380 gives you 280 frames across 108 minutes, or roughly 23 seconds per frame. Interpolating linearly across that range puts every frame within a couple of minutes of its real capture time, which is far better than the recovery timestamp the files currently carry.
Three sources improve the estimate:
- The DCIM folder name. Cameras write images into numbered folders such as
100CANONor100_0412. The trailing number usually encodes a date (month and day) or a sequence, and a folder name is often recoverable even when individual EXIF blocks are not. The naming conventions cameras use are described in the explanation of how cameras write files. - The first and last frames of the shoot. Marking the start and end times from your own notes bounds the interpolation and prevents drift.
- A surviving sibling file. If one image in the shoot kept its EXIF block, its timestamp is a ground truth you can anchor the interpolation to. A single intact file can correct an otherwise approximate estimate for the whole sequence.
Where the shoot crosses midnight, or where a card was used on more than one day, split the interpolation into segments rather than fitting one line across the whole set.
Batch-writing metadata with ExifTool
ExifTool is a command-line utility that reads and writes metadata across virtually every camera format, including JPEG, TIFF, HEIC, and the major RAW types. It is free, it is scriptable, and it is the correct tool for this job.
The working sequence has four steps.
1. Survey what is there. Before writing anything, list the current state of a folder so you know what you are replacing:
“ exiftool -T -FileName -DateTimeOriginal -CreateDate -r C:\recovered “
2. Back up the folder. ExifTool writes in place by default. Copy the recovered folder once and work on the copy.
3. Write a single value across a set. For a shoot with one known date and a fixed offset:
“ exiftool -AllDates="2019:06:14 14:32:00" -Artist="Your Name" -Copyright="(c) 2019 Your Name" -overwrite_original -r C:\recovered “
-AllDates is shorthand that sets DateTimeOriginal, CreateDate, and ModifyDate together, which matters because different applications read different ones.
4. Use a CSV when each file needs its own value. This is how you apply interpolated timestamps to a whole sequence:
“ exiftool -csv=times.csv -r C:\recovered “
The CSV needs SourceFile as its first column and one column per tag, for example SourceFile,DateTimeOriginal,Copyright,Keywords. Build it with a spreadsheet from your interpolation table.
Two details prevent most of the confusion. Writing EXIF timestamps does not change the file’s modification time on disk, and Lightroom, Photo Mechanic, and Windows Explorer each sort on a different key — add -FileModifyDate-o %d%f.xmp writes one instead, which Lightroom reads for many fields.
Copyright and rights fields for client delivery
Rights metadata is the easiest part of this job and the one clients actually check. Three tags cover what most delivery specifications ask for:
Copyright(EXIF), which older software displaysXMP-dc:Rights, the modern field most asset management systems readXMP-dc:CreatorandArtist, which identify the author
Write all of them in one pass. A single -Copyright flag that populates only the EXIF field will look correct in an old viewer and empty in a stock library or a client's DAM system. Adding -Keywords at the same time handles the classification that a recovered shoot has also lost.
The same principle applies to video delivery with different containers, covered in the guide to repairing corrupted video files.
Checking the result before you deliver
Verify on a sample before processing the whole set, and verify again afterwards.
Read back the tags on a handful of files — the same exiftool -T survey command from step one — and confirm that capture time, creator, and copyright are present and correct. Then open two or three files in the applications the client will use: a catalog application such as Lightroom, and a plain file browser. If the dates sort correctly in both, the writes are consistent.
Finally, spot-check the images themselves. Metadata work does not touch image data, but a file that was already partially damaged can be made worse by a careless bulk operation, and confirming that the pictures still open is a two-minute check. The broader verification procedure for a recovered set is set out in the guide to verifying recovered files.
If you are on Windows and the card 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 metadata tool can compensate for it.
Frequently Asked Questions
Can lost EXIF data be recovered?
Not the original values, unless a copy exists somewhere — an import catalog, a Lightroom sidecar, a cloud backup, or a delivered JPEG that kept its metadata. What can be done is reconstruction: capture times interpolated from filename sequences, and rights, keywords, and creator fields written from your own templates. GPS can be restored exactly if you have a time-matched track log.
Why is the date on my recovered photos wrong?
Because the timestamps you see are from the recovery process, not from capture. When a tool writes recovered files to your destination drive, the operating system stamps them with the current time. Every file from the shoot will share an identical timestamp until you write the reconstructed capture times back in.
What is the fastest way to add copyright to hundreds of photos?
One ExifTool command with -r for recursion and -overwrite_original, setting Copyright, XMP-dc:Rights, and XMP-dc:Creator in a single pass. It takes seconds for a few hundred files and avoids the mismatch that appears when only the legacy EXIF field is written.
Does writing EXIF change the image itself?
No. EXIF and XMP are metadata blocks inside the file wrapper, and writing them leaves the compressed image data byte-for-byte unchanged. File size may shift by a few kilobytes, and some tools re-encode thumbnails, but the picture is untouched. Work on a copy anyway.