XMP Metadata and IPTC: The Fields That Actually Matter

XMP metadata is Adobe’s XML block for storing descriptive and rights information inside an image file: who made it, who to credit, what it shows, what a licensee may do with it. IPTC is the older newsroom standard that defined most of those fields in the first place, and XMP now carries them under the IPTC Core schema. Both can sit in the same JPEG at the same time, holding the same values, which is exactly why this gets confusing.

The short answer

A photo file can carry three separate metadata blocks:

• EXIF is what the camera wrote. Shutter, aperture, ISO, lens, timestamp, orientation, GPS coordinates. Nobody types this in.
• IPTC IIM is the 1990s newsroom format, a binary block of numbered records for caption, byline, credit and keywords. Old, still read by a surprising amount of software.
• XMP is Adobe’s XML container, introduced in 2001. It holds namespaced properties (dc:, photoshop:, Iptc4xmpCore:, xmpRights:) and has become the place most modern software actually looks.

If you only remember one thing: write your credit and copyright into IPTC and XMP together. Writing one and not the other is how a byline goes missing at the far end of a workflow.

Why the same value lives in two places

When Adobe introduced XMP, it did not delete IPTC IIM. Photoshop instead kept both blocks in sync, so a caption typed into the File Info panel landed in the IIM Caption/Abstract record and in dc:description at once. That behaviour stuck, and today most tools still mirror the overlapping fields.

The trouble starts when the two disagree, usually after an edit by software that understands one block and not the other. The IPTC’s own guidance is that XMP wins. In practice:

• Lightroom, Bridge, Capture One and most DAM systems read XMP first and treat IIM as legacy.
• Some older wire and print systems still read IIM only.
• ExifTool will show you both, side by side, with the group name in front of each tag.

So if a caption looks wrong somewhere downstream, check whether you are looking at the IIM copy or the XMP copy before you assume the file is broken. The EXIF viewer lists every block separately rather than merging them into one tidy list, which is the point.

Field mapping: human name to IPTC and XMP

This is the table worth bookmarking. The left column is what the field is called in most user interfaces. The right two are what a tool like ExifTool will show you.

Field (as you see it)	IPTC IIM	XMP property
Creator / Byline	By-line (2:80)	dc:creator
Creator’s job title	By-line Title (2:85)	photoshop:AuthorsPosition
Credit Line	Credit (2:110)	photoshop:Credit
Source	Source (2:115)	photoshop:Source
Copyright Notice	Copyright Notice (2:116)	dc:rights
Rights Usage Terms	none	xmpRights:UsageTerms
Web Statement of Rights	none	xmpRights:WebStatement
Headline	Headline (2:105)	photoshop:Headline
Description / Caption	Caption-Abstract (2:120)	dc:description
Description writer	Writer-Editor (2:122)	photoshop:CaptionWriter
Keywords	Keywords (2:25)	dc:subject
Title / Object Name	Object Name (2:5)	dc:title
City	City (2:90)	photoshop:City
State / Province	Province-State (2:95)	photoshop:State
Country	Country-PrimaryLocationName (2:101)	photoshop:Country
Sublocation	Sub-location (2:92)	Iptc4xmpCore:Location
Date Created	Date Created (2:55)	photoshop:DateCreated

Two things stand out. Keywords are dc:subject, not dc:keywords, which catches people out constantly. And Rights Usage Terms has no IIM equivalent at all, because licensing language postdates the 1991 spec. If your licence terms need to travel with the file, they travel in XMP or not at all.

The fields that pay

Most photographers fill in five and skip the rest. That is usually the right call, but the five should be the right five.

Creator. Your name, spelled the way you want it printed. This is the field a picture desk pulls into a byline.

Credit. Often not your name. It is the agency or publication the image is licensed through, and a stock library will overwrite it with their own.

Copyright Notice. The full string, for example © 2026 Jane Okafor. All rights reserved. Some workflows also set the EXIF copyright status flag alongside it.

Rights Usage Terms and Web Statement. Plain text terms plus a URL to your full licence page. These are the two fields that make an image self-documenting when it gets forwarded around inside a company.

Description and Keywords. Description is a sentence about what is happening, who is in the frame, and where. Keywords are the search terms. Stock libraries index both, and a thin description is a common reason a submission gets rejected.

Location fields are the ones most often left empty. City, State, Country and Sublocation are text. GPS coordinates are numeric and live in EXIF. Filling in one does not fill in the other. Our geotagging tool writes both, so a picture desk searching “Rotterdam” and a map view both find the file. More on the coordinate side in what is geotagging.

Who reads what

• Stock libraries (Getty, Alamy, Adobe Stock) ingest XMP on upload and map Description and Keywords into their own search index. Most rewrite Credit to their house format.
• Picture desks run wire images through systems that read IIM, XMP or both depending on how old the system is. Byline and caption are non-negotiable.
• DAM systems (Bynder, Canto, Cumulus) read XMP and let an administrator map any property to an internal field.
• Lightroom and Bridge read and write XMP, either embedded or in a sidecar .xmp file for raw formats where the original must not be modified.
• Browsers and social platforms read almost none of it, and many discard it.

What our geotagger writes

The geotag tool runs ExifTool compiled to WebAssembly inside your browser. When you fill in title, description, keywords, creator, copyright and place names, it writes each value into the IPTC IIM record and into the matching XMP property at the same time: dc:title, dc:description, dc:subject, dc:creator, dc:rights, plus the photoshop: and Iptc4xmpCore: location fields. GPS goes into EXIF as coordinates.

The reason for writing all of them is the disagreement problem above. If a downstream system only reads one block, it still finds the value.

Steps:

1. Drop your files onto the tool. Up to 5 per batch on the free tier, 50 on Pro.
2. Search for a place or click the map to set coordinates.
3. Open the metadata fields and fill in Creator, Copyright, Description and Keywords.
4. Click Apply & Download.

Nothing is uploaded. The file is read and rewritten in the browser. If you want to check that claim rather than take it, open DevTools, watch the Network tab while you process a file, or turn off your wifi and do it anyway. Formats are JPG, PNG, WebP and TIFF. HEIC can be read but not written, because writing it would mean re-encoding to JPEG, so convert HEIC to JPG first if that is your source.

The caveat that ruins everything

Plenty of platforms strip metadata on upload. Facebook, Instagram, X and Twitter, Discord and WhatsApp all remove most or all of it during their re-encode. Google Business Profile strips EXIF from uploaded photos. Once it is gone it is gone, and there is nothing in the file to re-attach it to.

Two things follow. Embedded metadata is not a copyright enforcement mechanism on social platforms: it survives email, cloud storage, FTP delivery and most CMS uploads, and it does not survive Instagram. And since Google strips EXIF from Business Profile images and has said location metadata is not a ranking factor, geotagging photos will not improve your search rankings. Do it because picture desks, DAM systems and your own archive search need it.

Before you deliver a set of files, check three things: that the Creator and Copyright Notice are populated, that the Description is a real sentence rather than a filename, and that Keywords landed in dc:subject. Run one finished file through the EXIF viewer to confirm all three blocks agree. If you are sending files somewhere they should carry no location at all, strip the GPS and leave the credit fields intact.