PicaJet

Reference Glossary

Sidecar file

A separate file — typically with a .xmp extension — stored alongside an original asset to carry metadata that the original file format can't embed, without altering the source file itself.

Why it matters in a DAM

Camera RAW formats (Canon .CR2/.CR3, Nikon .NEF, Sony .ARW) are proprietary and often can't safely be written into after capture, so edits, ratings, and keywords applied in tools like Adobe Camera Raw or Lightroom get saved to a matching .xmp sidecar instead — the original RAW file stays bit-for-bit untouched. A DAM has to treat the pair as a single logical asset; if it ingests the RAW file but drops or disconnects the sidecar, all of that editing and tagging history is silently lost even though the pixel data is intact.

A worked example

Original file IMG_4471.CR2
Sidecar file IMG_4471.xmp
Sidecar contents Lightroom develop settings, star rating, keywords, IPTC caption

Common mistake

An asset gets renamed, moved, or re-exported through a workflow tool that only handles the primary file, breaking the filename match that links it to its sidecar — the DAM then shows a RAW file with no rating, no keywords, and no edit history, even though a perfectly good .xmp file exists somewhere with all of it.

Sidecar files exist because some formats resist being written into directly. RAW image files are the classic case — they’re meant to preserve an unmodified sensor capture, so software avoids modifying them in place and instead writes metadata and non-destructive edit instructions to an accompanying XMP file with the same base filename. Video and audio workflows use the same pattern for formats or containers that don’t support rich embedded metadata natively.

Inside a DAM, sidecar handling is mostly invisible when it works: the system reads both files at ingest and presents them as one asset record. Problems surface at the edges of the workflow — file transfer tools, cloud sync services, or manual folder copies that move the primary file but leave the sidecar behind, or vice versa. Because the link between the two files is just a filename match (and sometimes a folder location), any process that renames one without the other breaks the pairing.

Some DAMs avoid the issue altogether by converting RAW files to a DAM-native preview and storing all metadata in their own database, treating the sidecar only as an import source rather than an ongoing dependency. That trades off round-trip fidelity with the original camera software for operational simplicity.

Frequently asked

What problem does a sidecar file solve?

Camera RAW formats like Canon .CR2/.CR3, Nikon .NEF, and Sony .ARW are proprietary and often can't safely be written into after capture. A .xmp sidecar file stores edits, ratings, and keywords separately so the original RAW file stays bit-for-bit untouched.

How should a DAM treat a RAW file and its sidecar?

As a single logical asset. If the DAM ingests the RAW file but drops or disconnects the sidecar, all the editing and tagging history applied in tools like Adobe Camera Raw or Lightroom is silently lost, even though the pixel data itself is intact.

What commonly breaks the link between a file and its sidecar?

Renaming, moving, or re-exporting an asset through a workflow tool that only handles the primary file breaks the filename match that links it to its .xmp sidecar. The DAM then shows a RAW file with no rating, no keywords, and no edit history, even though the sidecar data still exists somewhere.

What format do sidecar files typically use?

They're typically .xmp files, using the same XML/RDF-based XMP data model that's also used for metadata embedded directly inside other file formats.

Why can't RAW editing tools just write changes into the RAW file itself?

Because RAW formats are proprietary and manufacturers often don't support safe in-place edits — writing into the file risks corrupting it. The sidecar exists precisely to let editing tools record changes without touching the original capture data.

How can a DAM avoid losing sidecar data during migration or export?

By handling the RAW file and its .xmp sidecar as a linked pair throughout every workflow step — ingest, rename, move, and export — rather than treating the sidecar as an optional extra file that can be dropped without consequence.