EXIF, IPTC and XMP: What Lives in Each Metadata Standard

Three separate committees, three unrelated problems, roughly three decades between the first and the last. That is the origin of the exif vs iptc vs xmp confusion, and it accounts for almost everything that goes wrong with photo metadata today.

The International Press Telecommunications Council got there first. News photographs move between organisations, and somebody has to state who took the picture, what is happening in it, who to credit and what the licence permits. The Information Interchange Model answered that, and Photoshop popularised it in the early 1990s.

EXIF, first published in 1995 by the Japanese electronics bodies now known as JEITA and CIPA, was solving something else entirely: how a camera records what it measured at the instant of exposure. Adobe published XMP in 2001, an XML container built to hold any of it, later standardised as ISO 16684-1. Since 2005 the current IPTC standard has been defined as XMP schemas rather than as the old binary block.

Which is why three metadata standards now live inside the same photo, several of their fields describe the same thing, and different software picks a different winner. Write a caption and a copyright line, export a JPEG, and the client’s system displays the caption while showing the copyright field as blank. A colleague opens the same file and sees a completely different caption, one you typed three years ago and forgot about. Nothing is broken.

The division of labour is clean once you see it. EXIF records what the camera measured. IPTC records what a human asserted. XMP is a container that can hold both, plus edit history, plus anything else a vendor wants to define, and it can sit inside the file or in a separate file next to it. This is the reference post for the rest of this cluster: what belongs in each standard, which formats carry which, how conflicts get resolved, and the trade-off that never gets named, which is that stripping metadata for privacy also strips the copyright claim you spent time filling in.

The short answer

EXIF holds machine facts. Make, Model, LensModel, ExposureTime, FNumber, ISO, FocalLength, Orientation, DateTimeOriginal, the GPS block and the manufacturer’s private MakerNote. Your camera writes it and you rarely edit it.

IPTC holds human claims. Creator, Description, Headline, Keywords, Credit Line, Source, Copyright Notice, Rights Usage Terms, and named locations like city and country. It came out of news wire practice, and it is what picture desks and stock agencies read.

XMP is Adobe’s XML wrapper, standardised as ISO 16684-1. It can express EXIF values, IPTC Core and IPTC Extension fields, Camera Raw edit settings and document history in one packet. Modern IPTC is defined as an XMP schema, so “IPTC” now means either the old binary block or a set of XMP properties depending on context.

Practical rule: read EXIF for what happened at capture, read IPTC for what someone said about it, and expect XMP to hold the authoritative copy of both.

The division of labour, in one table

The row that matters most is the last but one. XMP is the only one of the three that was designed to exist as a separate file, and that single property is why RAW workflows look the way they do.

EXIF: what the camera measured

EXIF is structured like a TIFF file, which is odd until you know the history. Inside a JPEG it sits in the APP1 marker segment prefixed with the bytes Exif\0\0, and the content is a set of image file directories: IFD0 for the main image, an Exif IFD reached through tag 0x8769, a GPS IFD through 0x8825, and IFD1 describing the embedded thumbnail.

The tags worth knowing by number, because you will see them in raw dumps:

• 0x010F Make and 0x0110 Model, the manufacturer and body
• 0x0112 Orientation, values 1 to 8, where 1 is upright, 3 is 180 degrees, 6 is rotate 90 clockwise and 8 is rotate 270 clockwise
• 0x0131 Software, the writing application
• 0x829A ExposureTime, 0x829D FNumber, 0x8827 ISO (now formally PhotographicSensitivity)
• 0x9003 DateTimeOriginal, the shutter moment
• 0x920A FocalLength and 0xA434 LensModel
• 0x927C MakerNote, the manufacturer’s private block
• 0x8825 the GPS pointer, leading to GPSLatitude, GPSLongitude and their Ref tags

EXIF does contain an Artist tag (0x013B) and a Copyright tag (0x8298), which surprises people who assume it is purely technical. I would not rely on either. They are unstructured strings with no way to separate a name from contact details, no language handling, and patchy support in commercial software.

The MakerNote deserves a warning. It is undocumented, vendor-specific, often several kilobytes, and frequently holds the camera body and lens serial numbers. If you would rather not publish hardware identifiers that link every photo you have posted to the same body, that is the block to think about. The APP1 segment caps at roughly 64 KB, which is why unusually chatty MakerNotes sometimes get dropped by tools that repack the file.

IPTC: what a human asserted

IPTC exists because news photographs move between organisations and somebody has to say who took the picture, what is happening in it, who to credit and what the licence permits. The International Press Telecommunications Council defined the Information Interchange Model for that, and Photoshop popularised it in the early 1990s. In a JPEG, the legacy block sits in APP13 inside a Photoshop image resource with ID 0x0404.

Since 2005 the current standard has been IPTC Core, with IPTC Extension on top, both defined as XMP schemas rather than as the old binary format. So a modern file usually carries the same IPTC values twice: once in the legacy block for compatibility, once in XMP as the real copy.

The IPTC Core fields you will meet most often:

• Creator, Creator’s Job Title, and a structured Creator’s Contact Info block with address, phone, email and website
• Title (the legacy Object Name), Headline, Description, and Description Writer for whoever wrote the caption
• Keywords, Intellectual Genre, IPTC Subject Code and Scene Code
• Date Created
• Sublocation, City, Province or State, Country, and ISO Country Code
• Job Identifier, Instructions, Credit Line and Source
• Copyright Notice, Rights Usage Terms and Web Statement of Rights

IPTC Extension adds the fields that matter for releases and provenance: Person Shown, Model Release Status, Property Release Status, Artwork or Object, Event, Licensor, and the distinction between Location Created and Location Shown. Extension also defines Digital Source Type, whose controlled vocabulary includes a value for media created by a generative model. That field is one of the more honest attempts at labelling AI imagery, and the signals that suggest a photo has been edited or generated covers how much weight it can actually carry.

The length limits nobody mentions

The legacy IIM block caps each field at a fixed number of octets. Modern XMP does not, which means a value can round-trip perfectly in one block and get chopped in the other. These limits are the reason a copyright line sometimes appears complete in one application and truncated in another.

Octets, not characters. That distinction bites the moment you use anything outside plain ASCII.

Say Freya writes this copyright notice: © 2026 Freya Márquez / Márquez Studio. Editorial use only; no derivative works; licence expires 31 December 2027. Contact the studio to extend. It is 143 characters. Three of them are non-ASCII (the copyright symbol and two accented letters), and in UTF-8 each of those takes two bytes instead of one, so 143 characters becomes 146 octets. The legacy field allows 128. She is over by 18, and the block gets cut mid-sentence at “Contact the”.

Her XMP dc:rights value stays whole. An agency reading XMP sees the full terms. An older system reading the legacy block sees a licence notice that stops before the important part. Nothing errors and nothing warns her.

XMP: the container that holds the rest

XMP is RDF/XML wrapped in a processing-instruction envelope that starts <?xpacket begin= and ends <?xpacket end="w"?>. Being text, it is readable in any editor, which makes it far easier to debug than a binary tag directory.

It works through namespaces. Each prefix maps to a schema:

• dc: is Dublin Core, giving dc:title, dc:description, dc:creator, dc:subject (keywords) and dc:rights
• xmp: gives xmp:CreateDate, xmp:ModifyDate, xmp:CreatorTool, xmp:Rating and xmp:Label
• xmpRights: gives Marked, UsageTerms, WebStatement and Owner
• xmpMM: is media management: DocumentID, InstanceID, DerivedFrom and a History array of edit actions
• photoshop: gives Credit, Source, Headline, DateCreated, City, State and Country
• Iptc4xmpCore: and Iptc4xmpExt: carry the IPTC schemas described above
• crs: holds Camera Raw adjustment settings, which is how a RAW edit travels without touching the RAW
• tiff: and exif: mirror camera values into XMP so one packet can express everything

Two features make XMP more capable than the others. Values can be typed structures, so a contact block is a real object with fields rather than one string you have to parse. And text carries language alternatives, so a caption can exist in English and Spanish in the same file with both properly tagged.

In a JPEG, XMP occupies its own APP1 segment identified by the namespace URI http://ns.adobe.com/xap/1.0/, with an Extended XMP mechanism to split packets larger than the 64 KB segment cap. In TIFF and DNG it is tag 700, in PNG an iTXt chunk keyed XML:com.adobe.xmp, and in a PDF a metadata stream attached to the document catalog.

When the same field exists three times

Here is the practical headache in table form. Each row is one concept and three places it can live.

Three copies of one caption can hold three different strings, and nothing in any of the formats forces them to agree.

The Metadata Working Group, formed by Adobe, Apple, Canon, Microsoft, Nokia and Sony, published guidelines around 2010 to settle exactly this. In plain terms: treat XMP as the primary copy, write the same value into the legacy blocks for compatibility, and prefer XMP when they conflict. The group is no longer active, but most mainstream software still follows the shape of that advice.

Loosely, though. Some tools sync all three on save. Some write XMP only. Some read EXIF ImageDescription and ignore everything else, which is how a photo with a perfectly good IPTC caption ends up showing the camera’s default text instead. If a value looks wrong somewhere in your workflow, the first question is not “what did I type” but “which block is that application reading”.

Sidecar files, and why RAW workflows need them

A sidecar is a plain XML file sitting next to your image with the same base name and an .xmp extension. DSC_4417.NEF gets DSC_4417.xmp. Open it in a text editor and you will find the same RDF you would find embedded in a JPEG.

The reason it exists is caution. RAW formats are proprietary and only partly documented. Canon’s CR3, Nikon’s NEF, Sony’s ARW and Fujifilm’s RAF all have private internal structures, and writing into a container you do not fully understand risks corrupting the only original you have. So Camera Raw, Lightroom Classic and Bridge write keywords, ratings, captions, rights fields and every adjustment slider into a sidecar, leaving the RAW untouched. DNG is the exception, being documented and designed to be written into.

Sidecars carry one obvious hazard, and it costs people entire cataloguing sessions. Move, rename or archive the RAW without its .xmp and every keyword, star rating and edit is gone. No warning appears, because from the filesystem’s point of view you moved a file successfully. Two rules follow: move image and sidecar together, and confirm your backup tool includes .xmp files rather than filtering to image extensions.

Two similar-looking things are not XMP sidecars. iOS writes .aae files holding edit instructions in its own format, and Google Takeout exports include a .json per photo carrying the original upload metadata. Both matter, neither is XMP, and both get deleted by people tidying folders.

Which file formats carry which standards

Support is uneven, and this is where most surprises come from. Convert a JPEG to PNG and half your metadata can quietly vanish.

The conversion trap follows directly. Take a JPEG with full IPTC rights fields, convert it to PNG, or run the reverse trip with something like PNG to JPG, and the legacy IPTC block has nowhere to go in the destination format. A good converter maps what it can into XMP. Plenty do not, and simply write pixels.

To find out what survived, open the before and after files in the EXIF Viewer and compare the three blocks. It runs in your browser, so client work and family photos stay on your own machine, and it takes about ten seconds per file. That habit catches silent metadata loss long before a client does.

The fields worth filling in if you licence your work

If you sell or licence images, six fields do most of the work. Fill them once as a metadata preset and apply on import.

1. Creator, using your legal or trading name, spelled the same way every time.
2. Creator’s Contact Info, at minimum a website and an email you will still read in five years.
3. Copyright Notice, in the conventional form: the © symbol, the year of first publication, the rights holder. Keep it under 128 octets so the legacy block does not truncate it.
4. Rights Usage Terms, in xmpRights:UsageTerms, describing what a licensee may do. No length limit, so this is where the real detail goes.
5. Web Statement of Rights, a URL pointing at your licensing page.
6. Description and Keywords, which make the file findable six years from now.

A caveat that matters. Copyright metadata is an assertion, not a registration. In countries party to the Berne Convention copyright exists from creation without formality, but the remedies open to you can depend on national registration, and rules on removing copyright management information differ by jurisdiction. In the United States, 17 U.S.C. 1202 addresses the intentional removal or alteration of copyright management information. None of that is legal advice. If money or a dispute is involved, check with a qualified adviser where you are, because the answer genuinely changes by country.

The trade-off nobody names: privacy against attribution

Every privacy article ends with “strip your metadata before you post”. Every photography article ends with “always embed your copyright”. Both are reasonable. They point in opposite directions, and almost nobody says so.

Strip everything and you remove GPS coordinates, the camera serial number in the MakerNote, the device identifiers and the timestamps. You also remove your name, your contact details, your licence terms and the keywords that let a picture desk find you. The file becomes anonymous in both directions.

What you usually want is selective removal: location and hardware identifiers out, rights and description in. Lightroom’s export dialog offers exactly that through a metadata dropdown with options such as copyright only, or everything except camera and Camera Raw data, plus a separate switch for removing location. Many general-purpose strippers are all-or-nothing.

So pick by destination. Delivering to a client or an agency, keep everything except location. Posting publicly, strip aggressively, because the platform re-encodes and discards your metadata anyway. Where attribution matters on a public post, a visible credit does more work than an invisible field, which is why Watermark Image exists and why photographers still put their name in the caption.

For the removal step itself, Metadata Remover handles the general case across image files. Watch what any stripping tool defines as “metadata”, since the three blocks live in different segments and clearing one may leave the others sitting there.

The avoidable problems

Partial stripping is the most common failure and the least visible. A tool advertised as an EXIF remover clears the EXIF APP1 segment, and the XMP packet in the neighbouring segment survives with your GPS coordinates mirrored into exif:GPSLatitude. You did the responsible thing and the coordinates are still there. Check the output.

Encoding damage in the legacy IPTC block is the second. The old format predates UTF-8 consensus, and applications have assumed different character sets over the years. Accented names, Cyrillic, Greek and CJK text can come back as replacement characters after a round trip through older software. The XMP copy is normally fine, which is another argument for treating it as the master. Silent truncation follows the same pattern, per the octet limits above: a 40-character credit line fits 32 octets in exactly zero cases.

Export presets drop metadata without saying so. Photoshop’s web export path has its own metadata setting that defaults to keeping very little, and plenty of batch resizers write clean files with no option at all. If you finish with a resizer or Image Compressor before delivery, check one output file before sending the set.

Two applications writing to different blocks produces the ghost-caption effect from the top of this article. Software A writes dc:description, software B reads EXIF ImageDescription, and the caption you see is whichever was written by whatever touched the file first.

And finally, orientation. EXIF Orientation is an instruction telling the viewer to rotate the image on display, not a change to the pixels. Strip metadata and a photo shot vertically can appear on its side, because the instruction is gone while the pixels sit in the sensor’s own arrangement. Bake the rotation in before stripping, not after. Capture dates behave similarly, being easy to lose and annoying to reconstruct, which the guide to repairing wrong capture dates covers in detail.

Auditing one file, step by step

Do this once on a file you have delivered recently. It takes five minutes and it usually finds something.

1. Pick a JPEG you have exported for a client or published, not a straight-from-camera original.
2. Open it in a viewer that shows all three blocks separately rather than merging them into one list. Merged views hide exactly the conflicts you are hunting for.
3. Read the EXIF block. Confirm the camera fields look right, then check whether the GPS block is present and whether the MakerNote carries serial numbers.
4. Read the IPTC fields. Look for a Creator, a Copyright Notice and a Description. Note anything truncated mid-word, which tells you a value overflowed an octet limit.
5. Read the XMP packet. Compare dc:description against the IPTC caption and against EXIF ImageDescription. If the three differ, decide which is right and correct it at source.
6. Check xmpRights:UsageTerms. In most files it is empty, and it is the field that does the real work in a licensing dispute.
7. Look at xmpMM:History if present. It can list every application that touched the file, which is occasionally more revealing than you expected.
8. Decide your two export profiles: one for delivery keeping rights and description, one for public posting keeping almost nothing. Save them as presets.

Frequently asked questions

What is the difference between EXIF, IPTC and XMP?

EXIF is what the camera measured: shutter speed, aperture, ISO, lens, orientation, GPS coordinates and timestamps. IPTC is what a person asserted about the picture: caption, creator, credit line, copyright notice, keywords and place names. XMP is Adobe’s XML container that can carry both of those plus editing history, and it can live inside the file or beside it as a separate sidecar.

What is an XMP sidecar file?

A sidecar is a small XML text file with the same base name as your image and an .xmp extension, holding metadata and edit settings for a file the software will not write into. RAW workflows use them because proprietary RAW containers are risky to modify. Move the image without the sidecar and every keyword, rating and adjustment stays behind, with no warning.

Which metadata field holds photo copyright?

Three do. EXIF has a Copyright tag at 0x8298, legacy IPTC has CopyrightNotice at 2:116, and XMP has dc:rights alongside xmpRights:UsageTerms and xmpRights:WebStatement. Professional software reads the XMP version first. Fill in the XMP fields, let your software sync the others, and add rights usage terms rather than only a copyright line, since the terms carry the useful detail.

Where should I put keywords, IPTC or XMP?

Put them in XMP as dc:subject, which is what modern software writes by default and what has no length limit. Legacy IPTC Keywords at 2:25 caps each entry at 64 octets and is only carried by JPEG and TIFF. Most editors write both automatically, so in practice you type keywords once and the software handles the duplication for you.

Does removing EXIF also remove IPTC and XMP?

Not necessarily. They are separate blocks in separate places, so a tool that strips the EXIF segment can leave the IPTC and XMP blocks completely intact, including GPS coordinates mirrored into XMP. Some tools clear everything, some clear only EXIF, and very few say which. Check the output file rather than trusting the label on the button.

Do PNG and WebP files support IPTC metadata?

Only through XMP. Neither format carries the legacy IPTC binary block, but PNG holds EXIF in an eXIf chunk and XMP inside an iTXt chunk, and WebP holds EXIF and XMP chunks in its extended format. Since IPTC Core is defined as an XMP schema, those fields still travel in both. Reader support varies by application, so verify rather than assume.

Where that leaves you

Three standards sounds like an accident of history, and partly it is. The split still makes sense. Camera facts, human claims and an extensible container for both are genuinely different jobs, and collapsing them would have meant either losing the machine data or asking a news agency to record shutter speeds.

The thing to hold onto is that one value can exist in three places with three different contents, and no format enforces agreement. When a caption or a copyright line shows up wrong, the question is which block that application read.

Fill in XMP properly, let your software mirror it, keep sidecars with your RAW files, and decide deliberately what leaves the building. A pass through the metadata viewer before you hand over a set costs a minute and settles it.