Dublin Core vs XMP vs IPTC: Choosing the Right Metadata Standard

These three standards emerged from different industries to solve different problems. Understanding their origins explains why they overlap in some places and diverge sharply in others.

Dublin Core started in 1995 at a workshop in Dublin, Ohio, where librarians and web developers needed a simple vocabulary for describing online resources. The result was 15 optional elements (Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights) that could be applied to any digital object. Dublin Core became ISO standard 15836 in 2003 and remains the backbone of institutional repositories, digital libraries, and open data portals worldwide.

XMP (Extensible Metadata Platform) was created by Adobe in 2001 and released with Photoshop 7. Rather than defining a fixed vocabulary, XMP provides a container format built on RDF and XML that can hold metadata from many different schemas, including Dublin Core and IPTC. XMP embeds directly inside file formats like JPEG, TIFF, PNG, PDF, PSD, MP4, and many RAW camera formats. It became ISO standard 16684-1 in 2012. Think of XMP as the envelope that carries metadata, not the vocabulary itself.

IPTC (International Press Telecommunications Council) Photo Metadata started in 1979 when news agencies needed a way to describe photograph content, ownership, and licensing. The original IPTC-IIM (Information Interchange Model) format was later supplemented by IPTC Core and IPTC Extension schemas, which are implemented using XMP. The standard is split into Administrative properties (creator contact info, workflow status), Descriptive properties (caption, keywords, location), and Rights properties (copyright notice, usage terms, license URL). Version 2025.1 added four new properties specifically for AI-generated content: AI System Used, AI System Version Used, AI Prompt Information, and AI Prompt Writer Name.

Here is a decision matrix that maps each standard against the criteria that matter when choosing one for your workflow.

Standard: Dublin Core

• Primary use case: Libraries, archives, institutional repositories, open data
• Supported formats: Format-agnostic (applied via HTML meta tags, OAI-PMH, RDF, or embedded via XMP)
• Embedding method: External (HTML head, XML sidecar, OAI-PMH harvesting) or embedded via XMP wrapper
• Extensibility: Qualified Dublin Core adds refinements; full extension via RDF-based DCMI Metadata Terms
• Vocabulary size: 15 core elements, expanded to 55+ properties in DCMI Terms
• Governing body: Dublin Core Metadata Initiative (DCMI)
• ISO standard: ISO 15836 (Part 1: 2017, Part 2: 2019)

Standard: XMP

• Primary use case: Creative workflows, photography, digital asset management, PDF documents
• Supported formats: JPEG, TIFF, PNG, GIF, PSD, AI, SVG, PDF, MP4, MOV, WAV, MP3, HEIC, WebP, and most RAW camera formats
• Embedding method: Embedded directly in file as XML/RDF packet
• Extensibility: Highly extensible, supports custom namespaces and schemas
• Vocabulary size: Container format, not a vocabulary. Ships with default schemas (dc, xmp, xmpRights, xmpMM) and hosts any additional schema
• Governing body: Adobe (open-sourced SDK), ISO
• ISO standard: ISO 16684-1:2019

Standard: IPTC Photo Metadata

• Primary use case: News photography, stock photography, editorial workflows, rights management
• Supported formats: JPEG, TIFF, PSD (IPTC-IIM); broader format support via XMP implementation
• Embedding method: IPTC-IIM binary block (legacy) or XMP-embedded IPTC Core/Extension (current)
• Extensibility: Fixed vocabulary with periodic version updates from IPTC working group
• Vocabulary size: ~80 properties across IPTC Core and IPTC Extension
• Governing body: International Press Telecommunications Council
• ISO standard: Part of ISO 16684-1 (XMP implementation)

The key architectural distinction: XMP is a container format that can carry Dublin Core and IPTC vocabularies inside it. Dublin Core and IPTC are vocabularies that define what metadata fields exist and what they mean. This is why a single JPEG file can contain Dublin Core elements, IPTC Core properties, and EXIF technical data, all stored within an XMP packet.

Turn File Metadata into Structured, Queryable Data

Fast.io Metadata Views extract structured fields from any file format using natural language. No rules to write, no format-specific parsers. 50 GB free, no credit card required.

Sign Up Free

A common source of confusion is that these standards are not mutually exclusive. A JPEG file edited in Lightroom or Photoshop typically contains three separate metadata blocks:

• EXIF block: Camera settings, GPS coordinates, timestamps (written by the camera hardware)
• IPTC-IIM block: Legacy binary format with caption, keywords, byline (still written for backward compatibility)
• XMP block: An XML packet containing IPTC Core properties, Dublin Core elements, EXIF mappings, and any custom schemas

Five Dublin Core elements map directly to IPTC Core fields:

• dc:title maps to IPTC Title
• dc:creator maps to IPTC Creator
• dc:subject maps to IPTC Keywords
• dc:description maps to IPTC Description/Caption
• dc:rights maps to IPTC Copyright Notice

When software like Adobe Bridge writes a caption to a photo, it writes the value to the XMP block under the Dublin Core namespace (dc:description) and simultaneously writes it to the IPTC-IIM block for backward compatibility. The IPTC specification explicitly recommends this dual-write approach to maintain interoperability with older software that only reads IIM.

This layering creates a practical risk: if different editing tools touch the same file without synchronizing all three blocks, the metadata can drift out of sync. ExifTool, one of the most widely used metadata utilities, handles this by reading all blocks and letting you choose which takes precedence. Professional DAM systems typically normalize metadata on ingest to prevent these conflicts.

The right standard depends on what you're describing and where the metadata needs to travel.

Choose Dublin Core when you need to catalog resources across a repository or data portal. Academic libraries, government open-data portals, and museum collections use Dublin Core because its 15-element simplicity translates across any subject domain. If you're building an OAI-PMH harvesting pipeline or exposing datasets for discovery, Dublin Core is the baseline that every aggregator understands. The Dumb-Down Principle means that even if you use Qualified Dublin Core refinements (like distinguishing "Date Created" from "Date Modified"), systems that only support Simple Dublin Core can still read the core value.

Choose XMP when you need metadata embedded directly inside files that move through creative production pipelines. Photographers, designers, and video editors benefit from XMP because the metadata travels with the file, not in a separate database. XMP's custom namespace support means you can define organization-specific fields (project codes, shoot identifiers, approval status) without breaking standard tooling. If you're using Adobe Creative Cloud, Capture One, or any modern DAM, XMP is already the primary read/write format.

Choose IPTC when your workflow centers on photograph description, attribution, and rights management. News agencies like Reuters and AP use IPTC because its vocabulary is purpose-built for editorial photography: structured location data (city, state, country, ISO country code), person and organization names, event descriptions, and detailed rights expressions. Stock photography platforms (Getty, Shutterstock, Adobe Stock) require IPTC fields for submission. If you're distributing photos commercially, IPTC compliance is not optional.

Use all three together when you're running a digital asset management system that handles mixed content types. A DAM ingesting photographs, PDFs, design files, and video clips needs Dublin Core for cross-format discovery, XMP as the embedded container, and IPTC for photo-specific editorial metadata. Most enterprise DAM platforms (Widen, Bynder, Canto, Orange Logic) normalize across all three standards on import.

Abstract comparisons only get you so far. Here is how these standards play out in real workflows.

Newsroom Photo Desk

A photojournalist shoots an assignment. The camera writes EXIF data (shutter speed, ISO, GPS). Back at the desk, the editor opens the images in Photo Mechanic or Adobe Bridge and fills in IPTC Core fields: headline, caption, byline, copyright, location hierarchy, and keywords. The software writes these values into both the XMP block and the IPTC-IIM block. When the images hit the wire service, downstream subscribers can read the metadata regardless of which format their systems support.

University Digital Repository

A library is digitizing a special collection of historical maps. Each scanned image gets a Dublin Core record: title, creator (cartographer), date, subject (geographic region), format (image/tiff), and rights (public domain). These records are exposed via OAI-PMH so that aggregators like Europeana and the Digital Public Library of America can harvest them. The actual TIFF files may also carry XMP-embedded Dublin Core for when researchers download and work with individual files locally.

Brand Asset Management

A marketing team manages thousands of product photos, design templates, and video clips. They use a DAM platform that reads XMP on ingest, mapping IPTC fields (keywords, usage rights, model releases) and Dublin Core elements (title, description) into a searchable index. Custom XMP namespaces track internal fields like campaign ID, approval status, and regional licensing. When an asset is exported for a social media campaign, the DAM writes updated XMP back into the file so the metadata follows the asset wherever it goes.

AI-Generated Content Labeling

With the IPTC 2025.1 standard, organizations producing AI-generated images can now embed provenance metadata directly into the file. The four new properties (AI System Used, AI System Version Used, AI Prompt Information, AI Prompt Writer Name) give downstream consumers a standardized way to identify synthetic content. This matters for newsrooms verifying source material, stock platforms filtering AI content, and compliance teams tracking provenance across mixed human/AI pipelines.

Reading individual metadata fields from files works fine for small collections. At scale, the challenge shifts from extraction to normalization: getting consistent, queryable data from files that use different standards, different software, and different levels of metadata completeness.

Traditional approaches involve writing format-specific extraction rules. You parse XMP with an XML library, decode IPTC-IIM binary blocks separately, and write mapping logic to reconcile conflicts when the same field appears in multiple blocks with different values. Tools like ExifTool and Apache Tika handle the format-level parsing, but you still need a pipeline to normalize, deduplicate, and store the results.

A newer approach uses AI to skip the rule-writing step entirely. Instead of defining extraction logic per format, you describe what data you want in plain language and let the system figure out how to get it from whatever file format it encounters.

Fast.io's Metadata Views take this approach. You describe extraction columns in natural language ("copyright holder," "creation date," "keywords," "AI-generated flag") and the system designs a typed schema, scans files in the workspace, and populates a sortable, filterable spreadsheet. It works across PDFs, images, Word documents, spreadsheets, and scanned pages without separate rules for each format. You can add new columns without reprocessing existing files, and agents can create schemas, trigger extraction, and query results through the Fast.io MCP server.

This matters for metadata standards work because real-world file collections are messy. Some photos have full IPTC Core metadata. Others have only EXIF. PDFs might carry Dublin Core in XMP or nothing at all. Rather than building extraction rules for every combination, structured AI extraction normalizes the output regardless of which standards the source files happen to use.

Other tools in this space include Apache Tika for server-side format parsing, ExifTool for command-line metadata extraction across hundreds of formats, and cloud services like Google Cloud Document AI for OCR-heavy workflows. Fast.io differentiates by combining extraction with persistent storage, workspace collaboration, and the ability to hand off results from agent workflows to human teams.