XMP, Sidecars & Lock-in — Will Your Edits Outlive Your Editor?

Last updated June 2026. Photo Developer is a Mac-native RAW developer that stores everything as plain-text XMP sidecars; this piece puts that choice in context rather than selling it.

The short version. Your metadata — ratings, keywords, labels, captions — is portable between apps, if your editor writes it to XMP. Your edits' actual look is not, in any app: every developer's adjustment math is its own, even when it's saved as readable text in an XMP file. What you can always keep is a transparent record of what the edit was. Photo Developer leans all the way into that — no catalog, everything in plain-text .xmp sidecars, with the basics written to Adobe's crs: namespace so they carry into Lightroom as a starting point. The full reasoning is below.

The fear that started this

Spend any time in photography forums and you'll meet a recurring worry, usually phrased something like: "I don't want to pour years of ratings, keywords and edits into a program, only to have it discontinued and lose all of it." It's a reasonable fear. People have lived it — with Aperture, with iView, with Picasa, with every catalog format that stopped being read.

The usual answer offered is "XMP sidecars." And that answer is half right in a way that's worth getting precise about, because the half that's wrong is exactly the half people are counting on.

So let's separate two things that constantly get conflated:

Metadata — your star ratings, color labels, keywords, captions, copyright, GPS.
Develop settings — your exposure, contrast, curves, masks, the actual look of the edit.

These two have completely different portability stories, and almost every "is my work safe?" conversation goes wrong by treating them as one.

The one rule that explains everything

Metadata is portable. Develop settings are not — even when they're written into an XMP file.

Metadata travels because it's written in shared, standardized namespaces (Dublin Core, IPTC, Adobe's xmp:Rating). A keyword is a keyword; a 4-star rating is a 4-star rating. Virtually every program reads these from an XMP sidecar or an embedded block.

Develop settings don't travel because every application uses its own adjustment math. Lightroom's "Exposure +0.50" and another app's "Exposure +0.50" are computed differently against the raw data, with different tone curves and different demosaicing underneath. There is no shared language for "the edit." So even when an app writes its adjustments into an .xmp file as readable text, that text is only meaningful to the engine that wrote it.

This is the crucial, counter-intuitive bit: "my edits are written to XMP" does not mean "my edits are portable." Lightroom writes its develop settings into XMP (the crs: namespace). darktable writes its entire edit history into XMP too. Both are sitting right there in a plain-text file — and neither can render the other's edits, because the namespaces and the math are their own. Writing to XMP buys you transparency (you can read it) and durability (it's not trapped in a binary blob), but not interchangeability.

The only cross-app transfer of develop settings that exists at all is one-directional and approximate: Capture One and darktable can import and translate Lightroom's adjustments into their own when you migrate, as a best-effort starting point — never identical, never reversible, and only from Adobe, not back to it. No app exports its look in a form a competitor can reproduce.

So the honest version of the reassurance is:

If an app dies, your ratings, keywords and labels survive and open anywhere — provided the app wrote them to XMP. Your edits' actual look is reproduced only by that app's engine. What you can always keep is a transparent, readable record of what the edit was.

That's still a real and meaningful safety net. It's just a different one than "all my work is portable."

Which apps will actually show the ratings and keywords you set?

"Metadata is portable" carries a quiet assumption: the other app has to actually read XMP sidecars. Most tools built for browsing and cataloguing do. Several popular apps don't — and it's worth knowing which, because a rating that doesn't show up looks like a bug when it's really a design choice on the other end.

Two patterns explain almost every "why can't I see my ratings?" moment:

Apps that keep their own library or database read metadata from their store, not from the .xmp next to your file. OM Workspace (OM System / Olympus), Apple Photos, and similar managed libraries fall here — the ratings you wrote to a sidecar simply aren't where they look.
Pixel editors aren't cataloguers. Pixelmator Pro, Affinity Photo, and Photoshop-as-an-editor open an image to work on its pixels; they have no ratings-and-labels browser to surface sidecar metadata in, so there's nothing to display it in.

Neither is reading your sidecar "wrong" — they're just not built to read it at all. The tools that are — and that pick up picks, star ratings, color labels and keywords from a standard XMP sidecar — include:

Adobe Lightroom Classic and Bridge / Camera Raw — read sidecar metadata (in Lightroom, on import or via Metadata → Read Metadata from File).
Capture One — when XMP sync is set to Load or Full Sync (it's off by default).
Photo Mechanic and FastRawViewer — the classic culling and ingest tools; XMP ratings and labels are their native language.
digiKam, XnView MP, and other XMP-aware browsers.
The DigTek suite itself — Photo Culler, Photo Archive Lite, and Photo Developer all read and write the same sidecar.

The practical rule: if an app is a browser, cataloguer, or culling tool that advertises XMP support, your ratings travel into it — sometimes after flipping a "read from file" setting. If it keeps its own database, or it's a pixel editor, expect to bring metadata across some other way, or to do your rating in a tool that speaks sidecars first and then hand the files on. When in doubt, the honest move is to check the app's own documentation for "XMP sidecar" support before counting on it.

How each developer actually stores your work

Here's where the six best-known developers land — what they store, where, and in what format.

Adobe Lightroom Classic / Camera Raw

Lightroom is catalog-first: everything lives in a central .lrcat database. Writing XMP sidecars for RAW files is opt-in — you switch on "Automatically write changes into XMP," or save metadata to file manually. When you do, Lightroom writes a plain-text .xmp containing both your metadata and its develop settings (the crs: namespace). As of Lightroom Classic 15, heavier edits (AI masks, Denoise) also spill into a companion .acr sidecar to keep things manageable.

The catch is the one above: those crs: settings are only fully understood by Adobe's own apps (Lightroom ↔ Camera Raw ↔ Bridge). Leave the Adobe ecosystem and the look doesn't come with you — only the metadata does. And because sidecar writing is off by default, plenty of Lightroom users have years of work living only in the catalog, which is the most lock-in-prone state of all.

Capture One

Capture One stores adjustments in its catalog database or, in Session mode, in per-image .cos files. It never writes develop adjustments to XMP. XMP for Capture One is strictly an opt-in metadata sync: in current versions you can set it to Full Sync (two-way metadata), Load (read-only), or None. That's an improvement on its historically weak reputation here, but it's still off or limited by default, and it never touches the original RAW.

What this means: your Capture One metadata can be made portable if you enable sync; your Capture One edits are Capture One's alone. It can read Lightroom's adjustments when you migrate in (one-way), but nothing reads Capture One's adjustments out.

DxO PhotoLab

DxO writes two sidecars by default, alongside a database: a proprietary .dop file holding the edit instructions, and an .xmp for metadata interoperability. Develop settings live in the .dop, not the XMP. From PhotoLab 5 onward DxO reads ratings from the .xmp, so metadata round-trips reasonably.

The .dop is human-readable text — transparent — but it's DxO-only, and DxO's signature optical corrections and DeepPRIME denoising are tied to its engine and per-lens modules. Readable, not portable.

darktable

darktable is the interesting case. It's catalog and sidecar, automatically — every edit is mirrored to a .xmp with no "save" step. And unlike Capture One or DxO, it does write its full edit history into that XMP. But it writes it in darktable's own namespace, not Adobe's crs:, so the history is transparent and durable but not readable by other apps.

darktable is also fully open-source, which changes the longevity calculus: even in the worst case, the format and the engine are open, so the edits are recoverable in principle, not just readable. One sharp edge: once darktable has imported an image, its database takes precedence and it will overwrite external changes to the XMP — so it's not a safe place to co-edit sidecars with other tools.

RawTherapee

RawTherapee uses a per-image .pp3 sidecar — a plain-text, INI-style file — and doesn't use XMP for edits at all. Its develop settings are maximally transparent (open text, open-source engine) but, like the rest, RawTherapee-only. Its .pp3 "cannot be natively read by other major editors," as its own documentation notes. Metadata it reads from standard embedded/XMP fields for display.

ON1 Photo RAW

ON1 writes two sidecars: a proprietary .on1 carrying the edits, and a standard .xmp carrying only metadata (ratings, keywords, IPTC). This is exactly why ON1 is popular as a sidecar-friendly companion to Lightroom — the metadata layer is clean and portable. The edits in .on1 stay with ON1.

The comparison, at a glance

Developer	Where edits live	Edit sidecar format	Are edits in XMP?	Metadata portable via XMP?	Are edits readable by other apps?	Edit record human-readable?
Lightroom Classic / ACR	Catalog `.lrcat` (sidecar opt-in)	`.xmp` (+ `.acr` for heavy edits)	Yes (`crs:`)	Yes	No — Adobe-only	Yes (XML text)
Capture One	Catalog DB / `.cos` (Sessions)	`.cos`	No	Yes, if sync enabled	No	Partly (`.cos` is proprietary text)
DxO PhotoLab	DB + sidecars (both, default)	`.dop` (+ `.xmp` for metadata)	No	Yes	No	Yes (`.dop` is readable text)
darktable	DB + `.xmp` (both, automatic)	`.xmp` (darktable namespace)	Yes, but non-Adobe	Yes	No	Yes (open text, open engine)
RawTherapee	`.pp3` sidecar (default)	`.pp3` (INI text)	No (no XMP for edits)	Reads standard metadata	No	Yes (open text, open engine)
ON1 Photo RAW	`.on1` sidecar (browse mode)	`.on1` (+ `.xmp` for metadata)	No	Yes	No	Partly (`.on1` is proprietary)
Photo Developer	`.xmp` sidecar only (no catalog)	`.xmp` (`crs:` + `pd:`)	Yes — basics in `crs:`, rest in `pd:`	Yes	Basics → Lightroom; signature tools no	Yes (plain-text XML)

A note on reading the last two columns honestly: no developer's signature edits are readable by another app — that row is "No" for everyone, and Photo Developer is no exception for its pd: tools (Tone Equalizer, Bloom, local adjustments). The one thing Photo Developer adds is that its basic tonal and color adjustments are written to Adobe's own crs: namespace, so they translate to Lightroom as a starting point. That's a portability floor, not portability of the whole look — and it's worth stating plainly rather than implying the entire edit travels.

Where Photo Developer sits

Photo Developer makes one deliberate choice the others don't: there is no catalog at all. Every edit is a number, and every number is written to a plain-text .xmp sidecar next to the RAW. There's no database that can corrupt, no library that can be orphaned, nothing to "export" your metadata out of — it was always in an open file.

Within that sidecar:

Metadata (ratings, keywords, labels, caption, copyright) uses the standard shared namespaces — fully portable, readable everywhere.
Basic develop settings (exposure, contrast, highlights, shadows, whites, blacks, white balance, parametric tone curve, HSL, vibrance/saturation, clarity, texture, dehaze, sharpening, crop, color grading/split toning, the black & white channel mixer, and lens corrections) are written to Adobe's crs: namespace — so they carry into Lightroom Classic as a faithful starting point.
Signature tools (Tone Equalizer, Bloom, Diffuse Glow, RGB and point curves, local adjustments, Fine Art tools) live in Photo Developer's own pd: namespace. Lightroom preserves them untouched but can't render them — same limitation every app has with its own special sauce.

There's a second, less obvious benefit to the all-sidecar design. Photo Developer is part of a small suite of Mac apps that share one sidecar with documented ownership rules: the browser/culler writes your ratings and keywords, the developer writes the edit, and each app reads, preserves, and never clobbers the others' data — all in the same readable .xmp. Your rating from the culler and your develop settings from the editor coexist in one file you can open in a text editor. That's "transparent" in the fullest sense: not just readable, but a single, documented, human-inspectable record of everything done to the photo.

What Photo Developer doesn't claim: that its full look is portable (no one's is), or that it replaces a serious DAM, or that it competes with DxO's optical corrections and denoising. It claims the narrower, honest thing — that your work is stored in the open, your metadata and basic edits aren't locked to it, and nothing about your archive depends on a database surviving.

So: will your edits outlive your editor?

Here's the durable takeaway, regardless of which app you choose:

Your metadata will survive — if your app writes it to XMP (sidecar or embedded). Turn that on. In catalog-first apps like Lightroom, it's off by default; that's the single most important setting for anyone worried about lock-in.
Your edits' exact look is tied to the engine that made it. That's not a flaw in any one app; it's a property of how RAW development works. Plan for it.
What you can keep forever is a transparent record of what the edit was — which apps store edits as open, readable text (XMP, .pp3, .dop, darktable's history) versus locking them in a binary catalog. When the readable record is also in a standard namespace for the basics, you get a portability floor on top of the transparency.

If long-term safety is your priority, the ranking that falls out of all this is simple: prefer apps that write to sidecars by default, prefer open and standard formats over proprietary databases, and always enable metadata-to-XMP wherever it's optional. That's true whether you land on Photo Developer, darktable, or anything else — and it's the most useful thing to know before you commit years of work to any of them.