What Is XMP Data in Photos?

XMP is a container: a block of XML that Adobe designed in 2001 to carry metadata of any kind, either inside the image file or in a small .xmp file sitting next to it. It is not a rival to EXIF or IPTC — it is the box that modern metadata gets written into, including most of IPTC and everything your raw editor knows about the photo.

XMP vs EXIF vs IPTC, in one table

	EXIF	IPTC	XMP
What it is	A fixed set of camera tags.	A vocabulary of editorial and rights fields.	A container that can carry any vocabulary — including IPTC.
Who defined it	The camera industry (JEITA/CIPA).	The International Press Telecommunications Council.	Adobe, in 2001; later published as ISO 16684-1.
Who writes it	The camera, at the moment of capture.	A human — photographer, editor, archivist.	Any software: editors, phones, drones, scanners, cameras.
Typical contents	Shutter, aperture, ISO, lens, GPS, timestamps.	Caption, keywords, creator, credit, copyright.	All of the above, plus ratings, edit settings, edit history, panorama and drone fields.
Format	A binary TIFF-structured block.	A binary block (IIM), or IPTC fields inside XMP.	Plain XML text you can open and read.
Where it lives	Inside the image file.	Inside the image file.	Inside the file, or in a `.xmp` sidecar beside it.

The short version: EXIF and IPTC are lists of fields; XMP is a place to put fields. That is why a photo can hold its copyright notice in both IPTC and XMP, and why stripping EXIF alone can leave your GPS coordinates sitting in the XMP packet.

Jump to what XMP is, what is inside it, embedded vs sidecar, how to view it, or how to remove it.

XMP: What It Stands For and Why Adobe Built It

XMP is the Extensible Metadata Platform, which Adobe published in 2001. The problem it was built to solve is in the first word. EXIF has a fixed list of tags defined by the camera industry; the legacy IPTC block has a fixed list of numbered datasets defined by a news body. Neither has a slot for "the exposure slider was pushed +0.7" or "this frame is one of 46 in a panorama" or "the drone was 82 metres up" — so every application was inventing its own private corner of the file to record such things.

XMP replaced that free-for-all with one rule: metadata is XML, and every property belongs to a namespace identified by a URL. Anyone can define a namespace. A reader that has never heard of drone-dji: can still parse the packet, show what it understands, and skip the rest without corrupting anything. That extensibility is the entire point, and it is why XMP won: the modern IPTC standard is defined as XMP properties, and Adobe, Google, DJI, and the open-source raw editors all write into it.

It is also readable. An XMP packet is text, wrapped in a pair of xpacket markers so tools can find it inside a binary file. Here is a real one, trimmed:

<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/">
   <xmp:CreatorTool>Adobe Lightroom Classic</xmp:CreatorTool>
   <xmp:Rating>4</xmp:Rating>
   <photoshop:City>Bristol</photoshop:City>
   <dc:creator><rdf:Seq><rdf:li>Jane Doe</rdf:li></rdf:Seq></dc:creator>
   <dc:rights>
    <rdf:Alt><rdf:li xml:lang="x-default">© 2026 Jane Doe</rdf:li></rdf:Alt>
   </dc:rights>
  </rdf:Description>
 </rdf:RDF>
</x:xmpmeta>
<?xpacket end="w"?>

The data model was standardised as ISO 16684-1, so XMP is no longer an Adobe-only specification even though Adobe wrote it. That padded xpacket wrapper is a practical detail rather than a curiosity: writers leave whitespace after the packet so a later edit can rewrite the metadata in place, without rebuilding the whole file.

What Is Actually Inside an XMP Packet?

Because XMP is a container, "what does XMP contain" is answered by listing the namespaces you will meet in a real photo. The prefix before the colon is what you see in a metadata viewer.

Namespace	Holds	Written by
`dc:`	Dublin Core — title, creator, description, subject (keywords), rights.	Almost every editor.
`xmp:`	CreateDate, ModifyDate, MetadataDate, CreatorTool, Rating, Label.	Editors and cataloguing apps — stars and colour labels live here.
`xmpMM:`	Media management: DocumentID, InstanceID, OriginalDocumentID, and a History list of every edit step.	Adobe applications.
`xmpRights:`	UsageTerms, WebStatement, Marked — the licensing fields.	Photographers, via metadata presets.
`photoshop:`	Headline, Credit, City, State, Country, DateCreated.	Adobe tools — these are IPTC fields under an Adobe prefix.
`Iptc4xmpCore:` / `Iptc4xmpExt:`	The modern IPTC standard: licensor contacts, depicted people, model releases, digital source type.	Agencies, picture desks, cataloguing tools.
`crs:`	Camera Raw develop settings — exposure, white balance, curves, crop, local adjustments.	Camera Raw and Lightroom. This is what a sidecar mostly is.
`exif:` / `tiff:`	EXIF and TIFF tags mirrored into XMP — including GPS coordinates.	Raw converters, and anything that migrates metadata.
`GPano:`	Panorama projection data that tells a viewer to render the image as a sphere.	Phone panorama and photo-sphere modes.
`drone-dji:`	Relative and absolute altitude, gimbal and flight angles.	DJI drones, on every frame.

The row that matters for privacy is exif:. When a converter copies EXIF into XMP, the GPS coordinates come with it, and you now have two copies of your location in the same file. Tools that promise to "remove EXIF" often mean exactly that and no more — the EXIF block goes, the XMP packet stays, and exif:GPSLatitude is still there for anyone who looks. This is the single most common way a supposedly cleaned photo still gives away where it was taken.

Where XMP Is Stored: Embedded vs Sidecar Files

Embedded — inside the image

For every format that has somewhere to put it, the packet goes in the file, and the photo carries its metadata wherever it goes:

JPEG— an APP1 segment tagged with the XMP namespace. A JPEG segment tops out around 64 KB, so a large packet (a long edit history, say) spills into extra "Extended XMP" segments.
TIFF and DNG — a dedicated tag in the image directory, which is why a DNG never needs a sidecar.
PNG — an iTXt chunk keyed XML:com.adobe.xmp.
HEIC, MP4, MOV — a box in the ISO container format the file is built from.
PDF, PSD, SVG — a metadata stream, a resource block, and a metadata element respectively.

Sidecar — a .xmp file next to the photo

Raw formats are the exception, and the reason is caution. A .CR3, .NEF, or .ARW is a proprietary, largely undocumented structure, and rewriting one to insert metadata risks damaging a file that cannot be regenerated. So Adobe Camera Raw, Lightroom Classic, Bridge, and darktable leave the raw untouched and write the XMP into a separate text file beside it.

# Adobe: same base name, .xmp extension
IMG_4831.CR3
IMG_4831.xmp

# darktable: appends .xmp to the full file name
IMG_4831.CR3
IMG_4831.CR3.xmp

A sidecar contains no pixels. It holds your develop settings, star rating, keywords, caption, and copyright fields — the whole of what an editor knows about the photo apart from the photo itself. Two consequences follow, and they catch people out in opposite directions.

Move one without the other and you lose it

Copy the raws to a new drive and leave the .xmp files behind and every edit, rating, and keyword is gone. They are a pair. Any backup or file-sync rule that filters by extension needs to include .xmp.

Hand over a folder and you hand over the sidecars

A sidecar can carry your name, your location fields, and a mirrored copy of the GPS. Sending a client "the raw files" sends that too — while an exported JPEG carries none of it, because the sidecar was never part of the image.

Lightroom Classic is the case worth knowing precisely. By default it keeps everything in its catalogue and writes no sidecars at all; the settings you want are Automatically write changes into XMP in the catalogue settings, or Save Metadata to File on a selection. Turn that on and your work becomes portable — readable by Bridge, by other raw converters, and by you after a catalogue loss. Leave it off and the catalogue is the only record.

So: do you need sidecar files? If you shoot raw and want ratings, keywords, and edits to survive outside one application, yes — keep them and move them with the raws. If you shoot JPEG or HEIC, you will probably never see one, because the packet goes inside the image. And if you find loose .xmp files next to photos you have already exported and no longer edit, they are safe to delete — you are discarding editing decisions, not pictures.

How to View XMP Data

In your browser

Drop a photo onto the metadata viewer on the home page — or the same tool on /exif-viewer — and open the All tab. XMP properties are listed there alongside the EXIF and IPTC ones, so you can see in a few seconds whether a file carries a packet and what is in it. The photo is read in your browser and never uploaded.

A sidecar is not an image, so the viewer will not take it — but you do not need a tool for that one. Open the .xmp in any text editor and read the XML directly. That is the practical charm of XMP: it is the one metadata block a human can inspect without software.

On the command line

ExifTool reads XMP from inside a file and from a sidecar, and can show you which group each value came from:

# Every XMP property, grouped by namespace
exiftool -a -G1 -s -XMP:all photo.jpg

# Dump the raw packet exactly as it sits in the file
exiftool -xmp -b photo.jpg

# Read a sidecar — same command, the .xmp is just a file
exiftool -a -G1 -s IMG_4831.xmp

# The privacy check: is there a second copy of the GPS?
exiftool -G1 -s -EXIF:GPS* -XMP:GPS* photo.jpg

In a GUI, the XMP fields appear under File Infoin Photoshop and Bridge and in the Metadata panel in Lightroom Classic — though each shows friendly labels rather than namespace prefixes, so you see "Creator" rather than dc:creator. The Windows and macOS file-properties dialogs are not reliable here: they surface a handful of fields and rarely tell you which block a value came from.

How to Remove XMP Data

Start from the trap: removing EXIF does not remove XMP. They are separate blocks, and a command or app aimed at one leaves the other in place. If the XMP packet holds a mirrored exif:GPSLatitude, a photo you believe is clean still says where it was taken.

# Remove just the XMP packet
exiftool -overwrite_original -xmp:all= photo.jpg

# Remove everything — EXIF, IPTC, XMP, the lot
exiftool -overwrite_original -all= photo.jpg

# A whole folder, recursively
exiftool -overwrite_original -r -all= ~/Pictures/to-share/

# Keep the copyright fields, drop the rest
exiftool -overwrite_original -all= \
  -tagsfromfile @ -XMP-dc:Rights -XMP-dc:Creator photo.jpg

In the browser, the Strip Metadata button in our viewer re-encodes the pixels into a fresh JPEG. That takes every block with it — EXIF, IPTC, and XMP together — because the new file is built from the image data alone and nothing else is copied across. It does not touch a sidecar sitting beside a raw file: delete that yourself if you are sharing the folder.

Most social platforms re-encode uploads and so discard XMP along with everything else, but that is their choice and not a guarantee — and it does nothing for a file you email, message, or hand over on a drive. Our guides on removing photo metadata and stripping metadata before sharing cover the per-platform steps on iPhone, Android, Windows, and Mac.

One thing to weigh before you strip everything. The XMP packet is also where your copyright notice, usage terms, and web statement live. Wiping it removes your rights information along with your GPS — which is fine for a photo of your front door, and a loss for work you want credited. The command above keeps the rights fields while clearing the rest, and our copyright page covers what those fields are worth.

Check the XMP in Your Own Photos

The quickest way to understand any of this is to look at a file you already have. Drop in a JPEG that has been through an editor and open the All tab: if you see properties with a crs:, xmpMM:, or dc: flavour, that is the XMP packet. Then drop in a photo straight off a phone and compare — many have no XMP at all until software touches them.

It runs entirely in your browser. Nothing is uploaded, and nothing about the file leaves your device.

Open the Metadata Viewer

Related Guides

What Is EXIF Data?

The block the camera writes at capture: every common field, and which formats carry it.

What Is IPTC Data?

The vocabulary that lives inside XMP: caption, keywords, creator, credit, and the copyright fields.

EXIF Data Explained

The deep dive: a full field glossary, how the blocks are structured, and which apps strip them.

Remove Photo Metadata

Step-by-step stripping on iPhone, Android, Windows, and Mac — and what each method actually removes.

Metadata Viewer

Read every tag a photo carries, XMP included, in your browser. Nothing is uploaded.

What Is GPS EXIF Data?

The location tags in detail — including the XMP copy that survives a careless clean-up.

Frequently Asked Questions

What is XMP metadata in photos?

XMP stands for Extensible Metadata Platform. It is a block of XML, published by Adobe in 2001 and later standardised as ISO 16684-1, that stores metadata either inside an image file or in a separate .xmp file beside it. Because it is a container rather than a fixed list of fields, it can hold anything: caption and keywords, copyright and usage terms, star ratings, raw develop settings, edit history, panorama geometry, drone altitude, and copies of EXIF values including GPS coordinates.

Is XMP the same as EXIF?

No. EXIF is a fixed set of tags the camera writes at capture — shutter speed, aperture, ISO, lens, GPS, timestamp — stored as a binary block defined by the camera industry. XMP is a container defined by Adobe that can carry metadata from any vocabulary, written by any software, and stored as readable XML. They coexist in the same photo, and a file often holds the same value twice: once as an EXIF tag and once mirrored into XMP. That is why removing EXIF does not necessarily remove your GPS coordinates.

Do I need XMP sidecar files?

Only if you shoot raw. Raw formats are proprietary and risky to rewrite, so Camera Raw, Lightroom Classic, Bridge, and darktable leave the raw alone and write your edits, ratings, keywords, and copyright fields into a .xmp file next to it. Keep those sidecars if you want that work to be portable between applications or to survive losing a catalogue — and move them with the raws, because a raw without its sidecar has forgotten everything. If you shoot JPEG or HEIC you will rarely see one, since the packet goes inside the image itself.

Can I delete .xmp files?

Yes — no pixels are lost. A sidecar holds only metadata and editing decisions, so deleting it returns the raw file to how it came off the card and discards the edits, ratings, and keywords recorded there. If your editor also keeps that work in its own catalogue, you lose nothing at all. If it does not, you lose the edits. Deleting sidecars before handing a folder to someone else is a reasonable privacy step, because they can contain your name and location fields.

How do I remove XMP data from a photo?

With ExifTool, run exiftool -overwrite_original -xmp:all= photo.jpg to drop just the XMP packet, or -all= to clear every metadata block at once. In a browser, our viewer's Strip Metadata button re-encodes the image into a fresh JPEG, which leaves EXIF, IPTC, and XMP behind together. Do not assume that a tool advertising EXIF removal has touched the XMP — check the result before you share it, and delete any .xmp sidecar separately.

Where is XMP data stored inside a JPEG?

In an APP1 segment near the start of the file, marked with the XMP namespace URI so readers can tell it apart from the EXIF APP1 segment next to it. A JPEG segment can hold roughly 64 KB, so packets larger than that are split into additional Extended XMP segments. Other formats use their own slot: a tag in TIFF and DNG, an iTXt chunk in PNG, a box in HEIC and MP4, and a metadata stream in PDF.

Why does the same field appear twice in my photo?

Because the shared fields genuinely exist in more than one block. A copyright notice can sit in EXIF's Copyright tag, in the legacy IPTC block, and in XMP as dc:rights; a capture date can sit in EXIF and in XMP. Adobe software has long written both copies and kept them in sync, while other tools write only one. If two copies disagree — because something edited one and not the other — different viewers will show you different answers for the same file, and neither is wrong.

Check the metadata in your own photos

Drop in a photo to see the XMP packet alongside every EXIF and IPTC field the file carries — and strip the lot in one click. It runs in your browser and nothing is uploaded.

Open Photo Metadata Viewer