What Metadata Standards Should Your DAM Use?

A metadata standard is a shared agreement about which fields to use, what they mean, and how values should be formatted. Without one, every team that touches your DAM invents its own field names, date formats, and controlled vocabulary terms. The result is a library that works for the team that built it and no one else.

The practical consequences show up in three recurring scenarios DAM practitioners encounter:

• Integration failures: When your DAM connects to a PIM, CMS, or creative suite via API, the receiving system expects specific field names. A DAM that stores photographer credit in a custom field called 'photo_credit' rather than IPTC's 'By-line' or Dublin Core's 'creator' requires a custom field mapping that breaks on every platform upgrade. Standards-compliant field names reduce that mapping debt significantly.
• Migration cost: DAM migrations are a known pain point in the industry. Assets with standards-compliant metadata - particularly XMP-embedded metadata - migrate cleanly because the new system can read the file's own embedded fields. Assets with bespoke schemas require a remediation pass before the new DAM can index them correctly. The scale of that remediation depends on library size and how inconsistently the original schema was applied.
• Rights enforcement gaps: Rights metadata - usage expiry dates, territory restrictions, model release flags - must be machine-readable to be enforceable at scale. IPTC defines exactly which fields carry that information and in what format, so a DAM can surface automated expiry warnings. A DAM that stores rights information in a free-text notes field cannot do this, which means someone has to remember to check manually - a compliance risk, not just an inconvenience.

Choosing a metadata standard is not a one-time technical decision made at implementation. It is an ongoing governance commitment that affects every team that creates, tags, or consumes assets.

Four standards appear most frequently in DAM implementations. Understanding what each covers - and what it does not - is the starting point for any metadata strategy.

Dublin Core

Dublin Core (maintained by the Dublin Core Metadata Initiative, DCMI) defines 15 core descriptive elements: title, creator, subject, description, publisher, contributor, date, type, format, identifier, source, language, relation, coverage, and rights. These elements are intentionally generic, which is both their strength and their limitation. Dublin Core maps to almost every DAM field set out of the box, making it the lowest-friction starting point for any implementation. Its limitation is that it does not cover domain-specific needs such as camera EXIF data, broadcast rights windows, or photographic credit structures - those require IPTC.

Where Dublin Core falls short in practice: The 'rights' element in Dublin Core is a plain text field with no enforced structure. Two teams filling it in independently will write it differently - one might enter 'All rights reserved', another a full license URL. That inconsistency is invisible until you try to run an automated rights audit. If rights management is a priority, IPTC's structured rights fields are more reliable than Dublin Core's free-text equivalent.

IPTC Photo Metadata Standard

The IPTC (International Press Telecommunications Council) Photo Metadata Standard is the default for photographic and journalistic asset libraries. It covers creator credits, copyright notices, usage terms, location data, and subject keywords in a format that most image editing tools and DAMs read natively. The standard has two layers: IPTC Core (the essential fields most DAMs surface in their UI) and IPTC Extension (covering model releases, property releases, and additional rights fields). For any DAM that holds photography at scale, IPTC is not optional - it is the field structure that rights management workflows depend on.

A common deployment edge case: IPTC fields are embedded in JPEG and TIFF files natively, but support for IPTC in PNG, WebP, and HEIC formats varies by DAM platform and by the tools used to write the metadata. Before committing to IPTC as your primary standard for a library that includes modern web formats, confirm with your DAM vendor which file types support IPTC write-back in their specific implementation.

XMP (Extensible Metadata Platform)

XMP is an ISO standard (ISO 16684-1) developed by Adobe that embeds metadata directly into a file rather than storing it only in a database. XMP uses an RDF/XML serialisation, which means it is both human-readable and machine-parseable. Because XMP travels with the file, it is the primary mechanism for metadata portability. A JPEG downloaded from your DAM carries its rights and credit information with it, regardless of which system the recipient uses. Most enterprise DAM platforms support XMP write-back as a configurable setting - check your platform's documentation to confirm it is enabled, because it is often off by default.

XMP write-back has a real operational cost: Writing XMP back to a file modifies the file's binary. For very large files - raw video, high-resolution TIFF masters - this write operation takes time and consumes storage I/O. Some organisations disable XMP write-back for master files and enable it only for derivatives. That is a legitimate trade-off, but it means your master files will not carry embedded metadata if the DAM is decommissioned. Document the decision explicitly in your governance policy.

Schema.org for Asset Pages

Schema.org is not a DAM-specific standard, but it is increasingly relevant for organisations that publish asset landing pages or embed DAM content in web properties. Applying Schema.org ImageObject, VideoObject, or MediaObject markup to those pages helps search engines and AI answer engines understand the asset's subject, creator, license, and rights status. This is a GEO (Generative Engine Optimization) measure: structured data makes your assets more likely to be cited by large language models and AI-powered search tools. For brand content hubs and asset portals that are publicly indexed, Schema.org markup is a practical addition to any metadata strategy.

No single standard covers every use case. The right combination depends on three factors: your primary asset types, your integration landscape, and your governance maturity. Work through these four steps in order.

Step 1: Identify your dominant asset types

• Photographs and editorial images: IPTC Photo Metadata Standard as the primary standard, with XMP embedding for portability. This is the combination used by news agencies, stock libraries, and brand photography archives.
• Video (marketing and brand): Dublin Core plus XMP. If you distribute to broadcast partners, add the IPTC Video Metadata Hub to cover rights and usage fields that Dublin Core does not define.
• Video (broadcast and production): SMPTE metadata standards for interoperability with editing and playout systems. Dublin Core and XMP still apply at the descriptive layer.
• Documents and mixed content: Dublin Core as the baseline, supplemented by domain-specific fields in your DAM's custom schema. XMP embedding is supported for PDF and many Office formats.

Step 2: Map your integration points

List every system your DAM connects to: CMS, PIM, creative suite, marketing automation, CDN. For each integration, identify which metadata fields the downstream system consumes. Standards-compliant field names reduce the number of custom transformations required in each connector - a practical time and cost saving that compounds across a multi-system stack.

Step 3: Assess your governance maturity

If your team is at an early stage of DAM governance, start with Dublin Core. Its 15 elements are manageable, well-documented, and supported by every major DAM platform. Add IPTC and XMP as your library grows and your rights management requirements become more specific. Attempting to implement all standards simultaneously before your team has a consistent tagging workflow in place typically results in partially filled fields across all standards - which creates more mapping problems than a single well-maintained standard would.

Step 4: Build and maintain a crosswalk document

A crosswalk maps equivalent fields across the standards you use. For example: Dublin Core's 'creator' field maps to IPTC's 'By-line' field and to Schema.org's 'creator' property. A maintained crosswalk is what makes migration, integration, and audit possible without manual field-by-field reconciliation. It is the single most important governance artefact for any multi-standard DAM implementation - and the one most often skipped until a migration forces the issue.

DAM practitioners who have run implementations or migrations consistently identify the same failure patterns. Knowing them in advance is cheaper than discovering them during a migration or a rights dispute.

• Inventing proprietary field names for things standards already cover: Custom fields for 'photographer name' or 'image date' that duplicate IPTC and Dublin Core fields create mapping debt. Every integration and migration must then handle both the standard field and the custom one. Audit your DAM's field list against Dublin Core and IPTC before adding any new custom field - the standard field may already exist.
• Storing metadata only in the DAM database, not in the file: Without XMP embedding, metadata is lost the moment an asset is downloaded or the DAM is decommissioned. Enabling XMP write-back in your DAM settings is a low-effort, high-value governance step that most platforms support natively. Check your platform's documentation under 'metadata write-back' or 'XMP synchronisation'.
• Treating controlled vocabulary as the same thing as a metadata standard: A metadata standard defines which fields exist; controlled vocabulary defines what values are allowed in those fields. Both are required. A 'subject' field that accepts free-text input is not governed, regardless of which standard it belongs to. Standards and taxonomy are complementary, not interchangeable.
• Skipping the crosswalk document: Teams that use multiple standards without a crosswalk accumulate silent inconsistencies. The same asset may carry a rights statement in its IPTC field and a contradictory one in its Dublin Core rights field, with no process to detect the conflict. A crosswalk makes those conflicts visible before they become compliance problems.
• Assuming your DAM vendor handles standards compliance for you: DAM platforms support standards to varying degrees. Check which XMP schemas your platform reads and writes, which IPTC fields it surfaces in the UI, and whether it exports Dublin Core on API responses. Vendor documentation is the authoritative source; do not assume a platform is fully standards-compliant because it markets itself as such.

This article focuses on the four metadata standards most relevant to general-purpose DAM implementations. It is a practitioner-oriented synthesis of publicly available standards documentation, not a substitute for consulting the standards bodies directly or engaging a certified implementation partner for your specific platform and use case. Specific limitations include:

• Archival standards such as EAD (Encoded Archival Description) or PREMIS, which apply to long-term digital preservation contexts rather than active marketing or media libraries.
• Industry-specific standards beyond broadcast, such as MARC (library cataloguing), DICOM (medical imaging), or GeoTIFF (geospatial raster data). If your DAM holds assets in these domains, consult the relevant standards body directly.
• Controlled vocabulary and taxonomy design - the term management work that determines what values populate standards-compliant fields. That is a separate governance discipline covered in other TdR guides.
• Specific DAM platform implementations - how a given vendor exposes or maps these standards varies. Consult your vendor's documentation or a certified implementation partner for platform-specific guidance.
• Edge cases in format support - XMP and IPTC support varies by file format and by DAM platform version. The edge cases noted in this article (PNG/WebP IPTC support, XMP write-back for large master files) are illustrative of the category of risk; your specific platform's behaviour may differ. Always test in a staging environment before enabling write-back on production assets.

Commercial interest disclosure: The DAM Republic is a vendor-neutral editorial hub. We do not receive payment from any metadata standards body or DAM vendor in exchange for coverage in this article.

What is the most widely used metadata standard for DAM systems?

Dublin Core is the most widely adopted baseline standard for DAM systems. Its 15 core elements - including title, creator, subject, description, date, and rights - map cleanly to the descriptive fields most DAMs expose out of the box. Many organisations use Dublin Core as a foundation and layer domain-specific standards such as IPTC on top for specific asset types like photography or video.

Do I need to pick just one metadata standard for my DAM?

No. Most mature DAM implementations use two or more standards in combination. A common pattern is Dublin Core for general descriptive metadata, IPTC Photo Metadata for image-heavy libraries, and XMP for file-embedded portability. The critical governance task is maintaining a crosswalk document that maps equivalent fields across standards so that data does not fragment when assets move between systems or DAM vendors.

What is XMP and why does it matter for DAM portability?

XMP (Extensible Metadata Platform) is an ISO standard (ISO 16684-1) that embeds metadata directly into a file's binary wrapper, rather than storing it only in the DAM database. This means metadata travels with the asset when it is downloaded, shared, or migrated to a new system. Enabling XMP write-back in your DAM platform settings is a practical portability safeguard that requires no custom development in most enterprise DAM platforms. Note that write-back behaviour for large master files and non-JPEG formats should be tested before enabling in production.

When should a DAM team consider Schema.org markup?

Schema.org markup is relevant when DAM-sourced assets or content pages are indexed by search engines or consumed by AI answer engines. Applying Schema.org MediaObject or ImageObject markup to asset landing pages helps search crawlers and large language models understand the asset's subject, creator, license, and usage rights. It is most valuable for organisations that publish asset portals or brand content hubs that are publicly indexed.

What metadata standard applies to video assets in a DAM?

For video, the most relevant standards are the IPTC Video Metadata Hub and, for broadcast workflows, SMPTE metadata standards. Dublin Core and XMP also apply to video files. Marketing DAMs typically use Dublin Core plus XMP for video; broadcast and media production environments often require SMPTE compliance for interoperability with editing and playout systems. Confirm with your DAM vendor which video metadata schemas it reads and writes natively before committing to a standard.