XMP (Extensible Metadata Platform) is a metadata standard, created by Adobe, that stores structured information directly inside a file using an open format — and unlike fixed-field standards, it can be extended with custom fields a specific workflow needs, not just the built-in ones.
In plain English
Older embedded-metadata standards like IPTC define a fixed list of fields — Creator, Caption, Copyright — and that's it; if your workflow needs a field the standard didn't anticipate, there's nowhere standard to put it. XMP was built to solve exactly that limitation: it's based on an open, extensible format (built on XML/RDF), so a photo agency, publisher or software vendor can define their own custom fields — a project code, an internal approval status, a usage restriction specific to their business — and store them right alongside the standard ones, inside the file itself. When the file itself cannot safely hold them — as with most proprietary RAW formats — the same XMP data is written to a sidecar file beside the image instead.
In practice, XMP and IPTC often coexist in the same file: many tools write IPTC's standard editorial fields and layer XMP's extended, custom fields on top for anything the fixed standard doesn't cover. Adobe's own products (Photoshop, Lightroom, Bridge) read and write XMP natively, which is part of why it's become a de facto standard across the wider photo and creative industry, not just Adobe's own ecosystem.
The tradeoff of that flexibility is less certainty: because anyone can define custom XMP fields, two different tools' "custom" fields won't necessarily mean the same thing to each other, unlike IPTC's fixed, universally-understood fields. Custom XMP fields work best within one organization's own consistent workflow, not as a way to communicate meaning to an outside party who's never seen your schema.
Why it matters in a DAM
Most libraries eventually need to track something the standard metadata fields don't cover — an internal project code, a licensing tier specific to the business, a custom approval stage. XMP is what lets that tracking live embedded in the file itself, surviving exports and transfers the same way IPTC's standard fields do, instead of living only inside one DAM's proprietary database where it's lost the moment the asset leaves that system.
Buyer’s test: ask whether the tool lets you define your own custom XMP fields, not just read the standard ones. Some DAM tools read existing XMP fine but only let you add custom metadata in their own proprietary database format — which means that custom data won't travel with the file if it's ever exported to another system.
Related terms
See it in action
See Adobe's own XMP documentation at adobe.com. For a DAM tool that reads and writes both IPTC and XMP fields directly in its metadata panel, see our Daminion.
FAQ
What is XMP in digital asset management?
XMP (Extensible Metadata Platform) is a metadata standard created by Adobe that stores structured information directly inside a file using an open, RDF-based format. Unlike fixed-field standards, it can be extended with whatever custom fields a specific workflow needs, which is why it became the common carrier for metadata that no older standard had a slot for. It is supported far beyond Adobe's own tools, and most serious DAM software reads and writes it.
What is the difference between XMP and IPTC?
IPTC defines a fixed list of standard editorial fields - Creator, Caption, Copyright, Credit - agreed on by the publishing industry. XMP is extensible: an organization can define its own fields on top of any standard ones. In practice they are not rivals. Modern IPTC data is commonly carried inside an XMP block, and many files hold both the legacy IPTC fields and their XMP equivalents, with IPTC covering the universal fields and XMP covering everything specific to your workflow.
How is XMP different from EXIF?
Different authors, different purposes. EXIF is written by the camera and describes the capture: exposure, lens, timestamp, sometimes GPS coordinates. It is technical and largely automatic. XMP describes meaning and rights - what the picture shows, who owns it, what a workflow needs to know - and is written by people and software after the fact. A single file usually carries both, and many tools copy selected EXIF values into XMP fields so everything is queryable through one structure.
Is XMP stored inside the file or in a sidecar?
Both, depending on the format. Where a format can hold an XMP packet - JPEG, TIFF, PNG, PDF, DNG - it is embedded in the file itself and travels with it. Where the format cannot safely be written to, which is the case for most proprietary RAW files, the XMP is written to a sidecar file sitting next to the original with the same name. Sidecars work, but they are separate files: move the RAW without its sidecar and the metadata is gone.
Why does XMP matter when switching DAM tools?
Because it is metadata you own rather than metadata the vendor holds. Anything written into a file's XMP travels with that file into the next system and needs no cooperation from the tool you are leaving. Anything living only in a vendor's database leaves through whatever export they offer, which usually means a CSV and a remapping project. Before you commit to a tool, export a few files and inspect them: if your fields are in the XMP, migration is a file copy rather than a negotiation.