What are virtual copies in Lightroom Classic and when should you actually use them?

By David · June 1, 2026 · 8 min read

Most photographers discover virtual copies by accident - right-clicking in the filmstrip and noticing "Create Virtual Copy" - then use them once, get confused about where they went, and forget the feature exists. That's a shame, because virtual copies are the single most underused workflow tool in Lightroom Classic.

I've been building Lightroom Classic plugins for a few years now, and the moment a virtual-copy workflow clicked for me was when I started managing publish services. One file going to three different destinations - full resolution to Google Photos, square crop to Instagram, watermarked JPEG to a client proof gallery - each needing its own develop settings, none of them messing with the others. Virtual copies are the right tool for exactly that. Here's how they actually work.

What exactly is a virtual copy - and what does it not do to your disk?

When you create a virtual copy, Lightroom adds a new row to its catalog database. That row has its own develop settings, crop, metadata, and collection memberships. The file path column? Points to the same original as the master.

Nothing is written to disk. No second CR3. No copy of the RAW. Just a few kilobytes of catalog data. You can create twenty virtual copies of a 50 MB file and your disk usage doesn't change by a single megabyte.

Lightroom identifies virtual copies with a small turned-page badge in the lower-left corner of the thumbnail. That's the entire UI signal - easy to miss at first, impossible to unsee once you know it.

Here's what virtual copies don't do: they don't protect your original. They're not a backup. If you delete the master photo from your catalog (and from disk), all virtual copies disappear too, because they have nothing to point at.

How to create, rename, and organize virtual copies in Lightroom Classic

Three ways to create one:

1. Right-click any photo in Grid or Filmstrip → Create Virtual Copy
2. Photo menu → Create Virtual Copy
3. Keyboard shortcut: ⌘' (Mac) or Ctrl+' (Windows)

The new virtual copy lands right next to the master in your filmstrip, with a "Copy 1" label under it. You can rename it by clicking the label - or, better, use a meaningful name that describes its purpose: "Square crop", "B&W client", "Google Photos".

For organizing, the key insight is that virtual copies are independent catalog items. They can live in different collections, different publish collections, carry different keywords, and have completely different star ratings and color labels. The only thing they share is the original pixel data on disk.

Virtual copies vs Snapshots vs History - which tool for which job?

These three features all let you "save" different versions of a photo, and the overlap trips up a lot of people.

The short version: use History while you're editing, Snapshots to checkpoint a state you might want to revisit, and virtual copies when two or more versions of a photo need to live as independent, long-term residents of your catalog.

Five practical use cases for virtual copies

Here's where the feature earns its keep.

1. B&W alongside color

Convert a virtual copy to black and white in Develop. Now you have both versions in your catalog, each independently publishable, with zero disk cost. Apply a different preset, do a full HSL/B&W conversion - the master stays untouched.

2. Output-specific crops

Your full-frame horizontal master goes to one collection. A 1:1 square crop virtual copy goes to your Instagram publish service. A 4:5 vertical crop goes to a different one. Each crop sits in its own collection, gets published independently, and re-editing the master's develop settings doesn't ripple into the crops unless you want it to.

3. Style experiments without commitment

Before you commit to a heavy preset or a grade, duplicate via virtual copy. If the experiment goes sideways, delete the copy - the master is unaffected. No history-step hunting, no "wait, what did this look like before?"

4. Client selects at different processing levels

One virtual copy with a quick edit for the proof gallery. Another with the full grade for delivery. Same file, two catalog entries, managed separately. When the client picks their selects, you know exactly which virtual copy to export.

5. Publish targets - the killer use case

This is the one I use daily. A master RAW in the catalog, edited to taste. A virtual copy dedicated to the Google Photos publish collection - maybe resized, with a slightly punchier edit for phone screens. Another virtual copy for a watermarked web gallery. Each publish service tracks its own virtual copy independently. Re-editing the master never accidentally marks the Google Photos copy as needing re-upload.

Using virtual copies with publish services and smart collections

Here's the thing most tutorials miss: virtual copies can be added to publish collections independently of their master. That means you can build a workflow where the master never appears in a publish service at all - only purpose-built virtual copies do.

Here's a practical setup:

1. Shoot and cull normally. Your masters stay in folders and regular collections.
2. For each photo you want to publish, create a virtual copy named after the destination ("GP" for Google Photos, "IG" for Instagram).
3. Edit each copy for its destination - apply output sharpening, adjust the crop, set the right color space.
4. Drop each copy into the appropriate publish collection. The master stays untouched.
5. When you re-edit the master, the publish copies are unaffected - no accidental "marked for re-publish" across your whole library.

Smart collections work with virtual copies too. You can build a smart collection that finds all virtual copies with "GP" in the copy name, or all virtual copies with a specific color label, and use that as an inbox for publish prep.

Gotchas to know: syncing, exporting, and when virtual copies will trip you up

Virtual copies are powerful but they have a few sharp edges worth knowing before you build a workflow around them.

• Lightroom Classic sync (not Lightroom cloud): Virtual copies do not sync to Lightroom's cloud. Only masters do. If you rely on Lightroom's ecosystem sync to access edits on your phone, virtual copies are invisible there.
• XMP sidecar files: Lightroom can write develop settings to XMP sidecars for RAW files. Virtual copy settings are not written to XMP - they only exist in the catalog. If you move photos to a new catalog without importing the catalog data properly, virtual copies don't come along for the ride.
• Export: Exporting a virtual copy exports it exactly like a master - with its own crop, settings, and metadata. The filename defaults to the master's filename, which can cause overwrite conflicts if you export multiple copies to the same folder. Add a suffix (like "_bw" or "_sq") to your export filename template.
• Stacks: Virtual copies and their master can be auto-stacked, which helps keep a busy filmstrip clean. Enable it under Photo → Stacking → Auto-Stack by Capture Time.
• Deleting a master: Deleting the master from the catalog will delete all its virtual copies too - you'll get a warning, but it's easy to dismiss without reading it. There's no way to "orphan" a virtual copy from its master.

So what does this mean in practice? Build your virtual-copy workflow around the catalog, not around XMP or cloud sync. Back up the catalog (Lightroom prompts you; actually do it). And always give virtual copies a descriptive name so you know at a glance which copy is which six months from now.

Virtual copies are one of those features where once you start using them intentionally, you wonder how you ever managed output targets without them. One file, multiple outputs, zero disk cost - that's a genuinely good design.