Camera metadata EXIF XMP is not one record kept in one place. It is three separate systems that happen to describe the same frame: the EXIF block the camera writes inside the file, the XMP packet that editing software writes inside or beside it, and the timecode and creation tracks inside a video container. They are authored at different moments by different software and they fail independently. That single fact settles most metadata questions after a recovery — whatever the camera embedded travels with the file, and whatever lived only in a catalog or a sidecar is gone unless you still have that catalog or sidecar.
So the practical rule is narrow. If your deliverable depends on a field, confirm it is embedded in the file rather than merely visible in an app.
Metadata Is Not One Thing: Three Independent Storage Layers
A photo on a card can carry metadata in three places at once, and a video in four. None is authoritative for the others.
| Layer | Where it physically sits | Written by | Travels when you copy the file? |
|---|---|---|---|
| EXIF | APP1 segment in JPEG/TIFF, Exif item in HEIF, IFD chain in RAW | Camera firmware, at capture | Yes, embedded in the file |
| Maker notes | Private tag block inside EXIF | Camera firmware | Yes, but only the same brand’s software reads it |
| XMP | APP1 segment in JPEG, uuid box in MP4/MOV, or a .xmp sidecar | Editing software, occasionally the camera | Partly, sidecars are separate files |
| Timecode and creation tracks | tmcd sample description, mvhd header, ©day and GPS atoms | Camera or external recorder | Yes, if the container header was closed cleanly |
The distinction that matters most: a copy of a file is a copy of everything embedded in it and nothing else. Ratings, keywords, and captions frequently sit in a catalog on your system drive, invisible to the card and absent from any recovered copy.
EXIF: The Block Inside Every JPEG, TIFF and RAW
EXIF (Exchangeable Image File Format) is a small binary structure modeled on TIFF, bolted onto the start of an image file. In a JPEG it lives in a marker segment beginning with the bytes FF E1, right after the FF D8 start-of-image marker and before the compressed scan data. Inside is a byte-order tag, then a chain of IFD (Image File Directory) blocks: IFD0 for the basics, an Exif sub-IFD for exposure data, and a GPS IFD when location was recorded.
What the camera writes at capture:
- Capture timestamp, down to the second, plus a time zone offset on bodies that support it
- Body and lens identity — make, model, sometimes a serial number
- Exposure triangle — shutter speed as an exact rational number, aperture, ISO
- GPS coordinates and altitude, on bodies with a receiver or a paired phone
- Orientation and an embedded thumbnail, a small decoded preview in the same segment
RAW files carry the same EXIF chain, because nearly every proprietary RAW format is a TIFF container underneath whatever extension the brand uses. That is why a CR3, NEF, or ARW can often be read up to the metadata layer by generic tools even when the image data needs the brand’s own decoder. The extensions differ, but the plumbing is broadly similar, as the breakdown of RAW formats by brand shows.
The counterintuitive part is which fields the camera actually owns. Orientation is routinely rewritten after capture — an editor that rotates an image usually updates the orientation byte rather than re-encoding pixels. And body identity is not always what it appears to be: some cameras and nearly all phone-derived files write a generic model string in EXIF while the real model sits in the private maker note block.
HEIF and HEIC files take a different route. They are ISOBMFF containers, the same family as MP4, and EXIF sits in a dedicated metadata item typed Exif rather than in an APP1 marker. The payload inside is the same structure.
XMP: The Parallel Metadata Your Editor Actually Uses
XMP (Extensible Metadata Platform) is Adobe’s XML-based metadata format, and it won a quiet war. It is the layer carrying everything a human typed: keywords, ratings, color labels, captions, creator and rights fields, and — for RAW workflows — the entire set of develop settings.
It has three possible homes, and which one applies changes everything about recoverability.
- Embedded in a JPEG or TIFF, in its own APP1 segment alongside EXIF, which is why one file can hold both a capture timestamp and a caption.
- Embedded in an MP4 or MOV, as a top-level
uuidbox. Action cameras use this heavily; a GoPro clip commonly carries both a GPMF telemetry track and an XMP packet describing lens correction. - As a separate
.xmpsidecar file next to the RAW. This is the standard for proprietary RAW formats, because rewriting the file itself for every rating change would be slow and risky.
A sidecar is plain text XML, and it is fragile in exactly the wrong way. It is not inside the image, so nothing protects it during a copy, a folder move, or a card-level recovery. When a photographer recovers 1,200 RAW files from a formatted card and finds every one reset to zero stars with no keywords, the images are intact and the metadata is simply not there — it was never in the files.
Timecode: The Video Metadata Almost Everyone Forgets
Video adds a layer with no still-photo equivalent, and it is the one most likely to go unnoticed until a timeline breaks.
Timecode is a frame-accurate address stored in a tmcd sample description inside the container, expressed as hours, minutes, seconds, and frames. Professional bodies can be synchronized to a common source, which is what lets an editor drop eight camera angles and six audio recorders onto a timeline and have them line up without manual nudging. Losing timecode damages no frames. It makes the material anonymous, and syncing forty clips by hand is the cost.
Alongside timecode, a container header carries a creation timestamp in mvhd and often a ©xyz atom holding GPS. GoPro adds a telemetry stream in its GPMF track, the data behind speed and g-force overlays. DJI writes private boxes for gimbal angles and flight parameters.
The catch is that all of it lives in the container header, which the camera finalizes at the end of a controlled stop. If the recording was interrupted by power loss, a crash, or a pulled battery, the header may be missing the moov atom that indexes everything else — and the timecode, creation date, and GPS atoms go down with it. The frames are still on the card in order. The labels that made them mean anything are not, until the index is rebuilt.
What Metadata Loss Actually Breaks
Missing metadata is not cosmetic. Each layer maps to a specific operational failure.
| What is lost | Immediate symptom | Who feels it |
|---|---|---|
| Capture timestamp | Everything sorts by copy time; clips land at the end of the timeline | Documentary and event editors |
| Timecode | Multicam sync must be rebuilt by hand or by waveform | Any multi-camera production |
| GPS coordinates | No mapping, no survey overlay, no proof of location | Survey, insurance, legal work |
| Creator and rights fields | Automated rights checks fail; delivery QA rejects the files | Commercial and stock delivery |
| Lens and exposure data | Lens correction profiles do not auto-apply; grain and color mismatch | Retouchers working in batches |
| XMP ratings and keywords | A 1,200-file archive arrives unlabeled | Anyone inheriting material |
| Maker notes | Brand software may refuse to apply its own profile to a RAW | RAW-first workflows |
The timestamp failure compounds, which makes it the worst of the set. When a recovery tool writes files to a new destination, the operating system assigns new modification times, so sorting by date returns the order in which the recovery ran rather than the order in which you shot.
What Can Be Rebuilt and What Never Comes Back
The dividing line is simple: metadata can only be reconstructed from evidence that still exists somewhere. If a value was never written, or was written only into a database you no longer have, no tool recovers it.
Usually recoverable with work:
- Capture date and time, inferred from internal timestamps, surrounding file sequence, and in-camera numbering. A folder rolling from
IMG_0998toIMG_1001brackets missing shots to within seconds, as the explanation of how a camera writes files to the card sets out. - Camera make and model, read from the file’s own headers and RAW signature.
- Orientation, from the thumbnail’s aspect or judged from the image.
- Thumbnails, regenerated by any RAW converter.
- Copyright text, if you have it written down and can batch-write it back — the operation covered in rebuild photo metadata.
Not recoverable, under any circumstances:
- GPS coordinates that were never recorded, because location services were off or the body has no receiver.
- Creator and copyright strings the camera never had, or that were only ever typed into a catalog.
- Keywords, ratings, and labels stored exclusively in a catalog that was lost or sits on a dead drive.
- Timecode that was never written, unless a matching second recording supplies it.
- Anything from a file whose image data is gone. Metadata attaches to data, not the other way around.
One consequence follows. If your work depends on metadata — a survey deliverable, a rights claim, a multicam sync — the only reliable protection is to have it embedded at capture and to copy file and sidecar together. Card settings matter here too, because the file systems cameras format to determine whether long clips are chaptered, and chaptering creates the timecode discontinuities editors trip over.
Where the Metadata Lives After a Recovery
Once files are recovered, the metadata that comes back is whatever was inside each file. That is the only guarantee; everything else depends on what else survived.
When the card is detected and mounts, and files are missing or unreadable, 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, preserving embedded EXIF and XMP blocks as it writes files out. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive. No tool can regenerate metadata that was never written, or rebuild a sidecar that existed only on a drive you no longer have.
Before deleting anything or formatting the card, open a representative sample and confirm the fields you need are present, using the sequence in verify recovered files before deleting the source. A file that opens is not automatically a file that still knows when it was taken.
Frequently Asked Questions
Does deleting a photo from the camera delete its metadata?
No. Deleting removes the directory entry and marks the clusters free; the file’s bytes, including the whole EXIF block, stay on the flash until those clusters are overwritten. Because memory cards do not implement TRIM, nothing erases them in the background. Deleted photos routinely come back with timestamps and GPS intact.
Why do my exported photos have no EXIF data?
Some export presets strip metadata deliberately, and social platforms remove most EXIF on upload as a privacy measure. Check the export dialog before assuming the data was lost at capture, and compare the original file rather than the exported copy.
Can recovered photos get their original capture dates back?
Sometimes. If the EXIF block survived inside the file, the timestamp is already there and only the file system dates need correcting. If EXIF was damaged, capture time can often be estimated from the in-camera file numbering and neighboring files, but that is an estimate rather than a record.
Do videos store metadata the same way photos do?
No. A video container holds timecode, creation time, and often GPS in header atoms rather than an EXIF chain, and XMP travels in a separate uuid box. Those fields are only as reliable as the container header, so an interrupted recording can lose its timecode even though every frame is on the card.