XMP Sidecar Metadata Handling

If your photo workflow involves multiple applications, XMP sidecar files can become surprisingly important. One application may store ratings in a .xmp file, while another prefers to write metadata directly into the image.

This raises an interesting question: What happens when a JPEG already has an XMP sidecar containing metadata such as a star rating, and you then rotate that image in Adobe Bridge?

The short answer is that Bridge can move relevant metadata into the JPEG’s embedded metadata, but it does not subsequently keep the external XMP sidecar synchronized.

Understanding that distinction is important if other applications in your workflow still depend on the sidecar.

Starting with a JPEG and an XMP sidecar

Imagine another photo-management application has created an XMP sidecar containing your rating:

photo.jpg
photo.xmp    ← contains rating metadata

When you open the folder in Adobe Bridge, Bridge can read the metadata associated with the image. The rating therefore appears in Bridge as expected.

At this stage, simply browsing the folder doesn’t necessarily require Bridge to rewrite either file.

The interesting part begins when you modify the image.

Rotating the JPEG in Adobe Bridge

Suppose you rotate photo.jpg from within Bridge.

For JPEGs, Bridge can store metadata directly inside the image file. Rotation information can therefore be represented through metadata associated with the JPEG rather than requiring the external sidecar to become the authoritative metadata store.

At the same time, metadata Bridge has read from the existing sidecar—such as the image’s rating—can become part of the JPEG’s embedded XMP metadata when Bridge writes metadata to the image.

Conceptually, you can end up with:

photo.jpg    ← rating + orientation/rotation metadata
photo.xmp    ← original rating metadata

The important point is that Bridge does not treat the external XMP file and the JPEG’s embedded XMP as two permanently synchronized copies of the same metadata.

The sidecar doesn’t become the master copy

This is where workflows involving several applications can become confusing.

Once metadata has been written into the JPEG, the image itself contains information that previously may have existed only in the sidecar. The original .xmp file can remain next to it, but Bridge does not necessarily update that sidecar every time the JPEG’s metadata changes.

You can therefore have two metadata stores:

JPEG
├── EXIF
├── embedded XMP
│   ├── rating
│   └── other metadata
└── orientation

XMP sidecar
└── rating from the original application

They may initially agree, but they should not be assumed to remain synchronized.

Why this matters

The problem becomes apparent when you return to another application.

Suppose the original program reads only:

photo.xmp

while Bridge has subsequently written newer metadata into:

photo.jpg

The two applications may now see different information.

For example, the external sidecar might still contain the original rating while newer metadata exists only inside the JPEG. Rotation information may likewise not be reflected in the sidecar.

In other words, the sidecar can become stale.

That’s not necessarily a problem if every application in your workflow understands embedded JPEG metadata. It becomes a problem when one application relies primarily—or exclusively—on external XMP files.

Embedded XMP vs. sidecar XMP

It’s useful to remember that “XMP” doesn’t necessarily mean “an .xmp file.”

XMP metadata can exist inside an image file or in a separate XMP sidecar.

For formats that support writable metadata, such as JPEG, Adobe applications can store XMP directly inside the file:

photo.jpg
└── embedded XMP

For formats and workflows where the original file shouldn’t or can’t be modified, metadata is commonly stored separately:

photo.raw
photo.xmp

This distinction explains why a workflow built around sidecars can behave differently once JPEGs are edited with an application that prefers embedded metadata.

Don’t assume Bridge will keep both copies synchronized

The most important practical lesson is simple:

An existing XMP sidecar should not be treated as an automatically synchronized backup of the JPEG’s embedded XMP metadata.

After modifying JPEG metadata in Bridge, don’t assume that:

photo.jpg metadata == photo.xmp metadata

If another application subsequently reads only the sidecar, it may see outdated information.

Likewise, simply deleting the sidecar because the metadata appears correctly in Bridge isn’t a good idea until you’ve verified that everything you need has actually been preserved in the JPEG and that no other application still depends on the external file.

Choosing a workflow

There are essentially three ways to deal with this.

Let embedded metadata become authoritative. If Bridge and other applications in your workflow correctly read embedded JPEG metadata, you can treat the JPEG as the primary metadata container. After verifying that ratings, labels, keywords, and other important fields have been preserved, old sidecars may no longer be necessary.

Keep a sidecar-oriented workflow. If another application depends on .xmp files, don’t assume that changes made in Bridge will automatically propagate back to those files. You’ll need to understand which application owns which metadata.

Synchronize explicitly. For more advanced workflows, a metadata utility such as ExifTool can be used to inspect and deliberately copy metadata between embedded XMP and sidecars. This is preferable to assuming that two independently writable metadata stores will somehow remain identical.

The takeaway

When a JPEG already has an XMP sidecar and you modify the image in Adobe Bridge, metadata from that workflow can end up embedded directly in the JPEG.

But that does not turn the external .xmp file into a synchronized companion.

The practical result can look like this:

Before:

photo.jpg
photo.xmp    ← rating


After Bridge writes to the JPEG:

photo.jpg    ← embedded metadata, including rating and rotation information
photo.xmp    ← original metadata, potentially unchanged

That distinction matters in any multi-application photo workflow.

If you use XMP sidecars for ratings, labels, keywords, or other organizational metadata, decide which copy is authoritative before moving back and forth between applications. Otherwise, you can easily end up with a JPEG and a sidecar that both contain valid metadata—but no longer tell exactly the same story.