Imagine spending a couple of afternoons doing nothing but keywording. No editing, no exporting — just sitting with two thousand frames from the spring and tagging them: coast, long-exposure, Lofoten, a star rating here and there. The kind of work that produces almost no new information. A few hundred kilobytes of words, total.

Then your backup wakes up and starts copying forty gigabytes.

Where the words actually go

When you rate or keyword a photo, that information has to be written down somewhere. There are only two places it can go, and the choice between them is usually made for you, silently, by whatever app you happen to be using.

The first option is to write it inside the photo — into the RAW, the DNG, the TIFF, the JPEG itself. The file already has a metadata section in its header; the app reaches in and edits it. Adobe's "write to file" does exactly this; so does any tool that embeds IPTC or XMP directly into the image. The appeal is obvious: one file, everything in it, nothing to lose track of.

The second option is to write it beside the photo — into a small companion text file with the same name and a different extension. 2026-04-08-0192-lofoten_dawn.raw keeps its keywords in 2026-04-08-0192-lofoten_dawn.xmp. The image is never touched. Everything you decide about it accumulates in the little file next door. This is the XMP sidecar, and it's the spine of how my own apps work.

Both store the same words. The difference only becomes visible when something has to copy them — which, if you back up at all, happens constantly.

How a backup actually thinks

A backup doesn't understand photographs. It understands files, and it asks one question on every pass: did this file change since I last saw it? If the answer is yes, it copies the file — and the smallest thing it can copy is a whole file.

This is the part most people never picture. The unit of backup is the file, not the edit. Time Machine, iCloud, Backblaze, Dropbox, a plain rsync to a second drive — they all version at the granularity of "this file is different now, take it again." A one-byte change and a total rewrite look identical from the outside: the file's modification date moved, so the file gets re-copied. Every byte of it.

So watch what happens when your metadata lives inside a 30-megabyte RAW. You add one keyword. The app rewrites the file's header to fit the new word, the modification date ticks forward, and as far as your backup is concerned a 30-megabyte file just changed. It copies all 30 megabytes — to capture nine bytes of the word coast. Do it across two thousand frames and you have asked your backup to move sixty gigabytes to record a few hundred kilobytes of actual thought.

That was the forty gigabytes. Not a single pixel had changed. You only described the pictures — and described them into the files, so every description dragged the whole negative along behind it.

"But my backup is smarter than that"

Some are, a little, and it's worth being honest about it. Block-level and deduplicating backup tools — Borg, restic, Backblaze's newer engine — don't always re-store an entire file; they can notice that only a few blocks differ and keep just those. If you run one of these, the penalty is smaller than the headline number.

Smaller, not gone. Two things keep the tax on the bill. First, even a dedup engine has to read and re-hash the entire file to discover that only a sliver changed — so a metadata pass still drags every byte of every touched RAW off the disk and through the CPU, even if less of it lands in the backup. Second, embedded metadata sits in the file's header, and growing a header by one keyword frequently shifts everything after it, changing the offsets of blocks that didn't conceptually change at all. Naive deduplication misses that and stores them again anyway. And the most common backup on a Mac — Time Machine — doesn't do any of this. It versions whole files. For most photographers, the headline number is the number.

DNG is the cruel twist

There's a particular irony here, and it stung me enough that I put a one-line grievance about it in an earlier post before I understood quite how deep it ran.

DNG was supposed to be the safe choice — the open, documented, archival RAW format you adopt precisely because you don't want to be locked in. But because it's a real image file with a real metadata section, embedding your ratings and keywords means rewriting the DNG. The format you chose for its longevity becomes the format your backup re-copies every time you touch a star. The openness is genuine; the backup behavior is the worst of both worlds. You get a file that anyone can read in fifty years and that your backup drive re-hauls every single afternoon you spend organizing.

The sidecar version of the same work

Now run that keywording session the other way. The two thousand RAWs are written once, when they come off the card, and then they are never modified again — not by a rating, not by a keyword, not by a develop edit. They are negatives. Write-once, back-up-once, done forever.

Every word I added that afternoon went into a sidecar — a two-to-ten kilobyte text file beside each frame. Those are what changed. Those are what the backup noticed. Two thousand tiny text files, a few megabytes in total, re-copied in the time it takes to notice it's running. The thirty-megabyte negatives sat untouched, already safe, already backed up, irrelevant to the day's work because the day's work never reached them.

That's the whole trick, and it isn't really about XMP at all. It's about putting the thing that changes constantly (your judgments) in a different container from the thing that never changes (the captured light). Embedding metadata welds them together, so the immovable object gets dragged around by the restless one. A sidecar keeps them apart, and your backup quietly stops doing pointless work.

What it costs you instead

I don't believe in selling a tradeoff as a free lunch, so here's the other side.

Sidecars double your file count. A folder of two thousand RAWs becomes a folder of four thousand items, half of them little .xmp files, and some people genuinely hate the visual clutter of that in Finder. The pair has to stay together, too — move a RAW and leave its sidecar behind and you've separated a photo from its history, with no tool able to reunite them for you. (The fix is discipline at ingest: name the pair identically and never split them. But it is a discipline you now have to keep.)

And embedding has one real advantage sidecars can't match: a single self-contained file travels well. Hand someone a JPEG with its keywords and copyright baked in and the words go with it, anywhere, through any channel, with nothing to fall off along the way. That's why exported, shared files — the disposable deliverables — are exactly where embedding makes sense, and why my own export pipeline writes metadata into the JPEG on the way out. The sidecar is for the archive you keep. The embed is for the copy you give away.

The turn

Backups reward you for telling the truth about what changed. Embed your metadata in your negatives and you tell your backup, two thousand times an afternoon, that a thirty-megabyte photograph is new when only a word is. Keep it in a sidecar and the negative gets to be what it actually is — finished, immovable, copied once and left alone — while your restless, ever-changing judgments live in a file small enough that backing them up costs nothing worth noticing.

It isn't a purity argument. It's just arithmetic that happens to line up with the right design. Put the changing thing where it's cheap to copy. Leave the permanent thing permanent.

Weniger, aber besser.

This is the backup half of an argument I make more fully in A File-Based Photo Workflow Without Lightroom. The apps that practice it — Photo Archive and Photo Developer — are part of the Photo Suite, a small collection of focused tools for the complete photography workflow on macOS. One-time purchase, no subscription.