Media Metadata Standards: EXIF, XMP, and Sidecars

Overview

Metadata is what makes an archive searchable, and it is stored in a surprising number of incompatible places: embedded in the file, in a companion sidecar, in a database, or in all three and disagreeing. Understanding which standard applies to which medium, and which survives which operation, is what prevents an archive from gradually losing the information that made it useful. This guide covers the main standards, where each lives, and the specific operations that strip them.

What You Need

• A tool that can inspect embedded metadata. ExifTool is the standard
• Sample files from each source you work with
• Knowledge of what your asset system stores versus what the files carry
• A test upload to each platform you publish to
• A decision about what is authoritative when they disagree
• A policy on what to strip before publishing, and what to keep

Steps

Pro Tips

• ExifTool reads and writes essentially everything and is worth learning even briefly. It is the reference implementation for this whole area.
• Never assume metadata survived a round trip. Check the output file, not the input.
• Keep sidecars in the same folder as their media and move them together. They are trivially orphaned.
• Timestamps are the most commonly corrupted field, timezone handling differs between tools and devices.
• Strip location data from anything shot at home or in a private location before it is published.

Tested: which operations keep or strip metadata in FFmpeg and Pillow

We tested the page's claims about what strips metadata on 2026-09-29 with FFmpeg 8.1.2, ffprobe and Pillow 12.3.0, on generated files. Seven fields (title, artist, comment, copyright, creation date, a custom project field and a location) were written into each container, and a JPEG got make, model, date, orientation and a GPS position. Each file was then copied, re-encoded, converted or stripped and the result was read back. ExifTool, the page's recommended reader, is not installed on the machine we used, so nothing here was read with it. No platform, screenshot or messaging app was tested.

Re-encoding audio and video with FFmpeg did not drop container metadata. By default it copies the fields across, so a re-encoded MP4 kept exactly what a stream copy kept, and the one field that went missing in both was the creation date, which did not survive an MP4 to MP4 pass in this build. The page says re-encoding and many conversion tools drop it, and that depends on the tool: Pillow's plain open and save did drop every EXIF field from the JPEG, and FFmpeg's re-encode of the same JPEG did as well.

What was lost mostly came from the destination container, not the operation. MP4 held six of the seven fields we wrote and left out the custom project field, WAV held four, and Matroska, MP3 and FLAC held all seven. Going from Matroska to MP4 lost the creation date and the custom field, and from MP3 to WAV lost three. Once a field is lost this way it is not there to return when the file is converted back. The page's advice not to treat embedded metadata as a system of record is borne out.

Step 5 had a trap in it, and now says so. Stream copying a JPEG with -map_metadata -1, the option that emptied the MP4 and WAV files above, left all five EXIF fields, GPS position included, in the JPEG. A re-encode or a resize with FFmpeg removed them, but converting to PNG kept the GPS position and lost only the orientation. So the command that strips a video does not strip a photograph, and checking the output file, as the page says, is the only way to know.

Pillow shows the other side of it. Saving a JPEG with its defaults dropped all EXIF, and passing the EXIF explicitly kept all of it. Whether a tool preserves metadata is a setting, and the default differs between tools.

Check what a file still carries, and strip the container fields of a video: ffprobe -v error -show_entries format_tags -of default=nw=1 out.mp4 && ffmpeg -i in.mp4 -c copy -map_metadata -1 out.mp4

Validated. Run 2026-09-29 with FFmpeg 8.1.2, ffprobe and Pillow 12.3.0 on generated files. Results are for these tools and versions. Each field counts as present when ffprobe lists it as a container tag. We did not test IPTC, XMP, sidecar files, ExifTool, video-specific fields such as timecode and reel name, any platform's upload processing, screenshots, or messaging apps, and we cannot say from this what any of them strip. The command is the one that was measured on video files, not on JPEG.