Duplicates: merging libraries without losing the best copy

Where duplicates come from, how to tell an exact copy from a near duplicate, which copy to keep, and how to merge one year or one folder with a backup in place and counts before and after.

Where duplicates come from Understand

A duplicate is a second copy of the same photo inside one library. Duplicates are not a sign that something went wrong. Copying a digital file is easy, and every route a photo travels can leave a copy behind. The Digital Preservation Coalition's note on personal archiving makes the same point and recommends deleting duplicates now and then, so the archive stays orderly and takes less space (DPC Topical Note 6).

Copy, check, then delete

Getting photos out teaches the rule this chapter rests on. You count the items at the source and in the copy, open a few from the copy, and remove nothing until both counts are written and either match or the difference is explained. This manual's rule Merging duplicates is a delete, so the same rule applies: a copy exists first, the counts go on the inventory, and a few pairs are checked by eye before the rest go.

Things that look like duplicates and are not

Some files come in pairs on purpose. Treat these as one photo, not two:

• A Live Photo. Apple says a Live Photo is exported as two separate files, a still image and a video (Apple's Export guide for Mac). Deleting the video half leaves a still that no longer moves.
• A raw file and its JPEG. A camera set to save both writes two files of one shot, with the same name and different extensions. Formats and the long term explains why both are kept.
• A sidecar file. An XMP sidecar is a small file beside a photo that holds its captions and keywords. It has the photo's name and the extension .xmp. It is not a photo.
• A scan's master and its sharing copy. A TIFF master and a JPEG made from it for sharing are kept on purpose (Prints, slides and negatives).

Burst shots and a dozen tries at one group photo are a different matter. They are separate photos that look alike. Keeping the best of them is a choice about what matters, which Choosing what to keep covers. This chapter deals with copies of one photo.

Exact copies and near duplicates

Two kinds of duplicate need different handling.

An exact copy is the same file, byte for byte. Nothing was changed when it was copied: not the pixels, not the date, not the name inside the file. An exact copy can carry a different file name, because the name sits outside the file's contents. Microsoft's documentation for its hash command says names and extensions can change without changing a file's contents or its hash (Microsoft Learn, Get-FileHash).

A near duplicate shows the same picture but is a different file. It was resized, re-saved, converted to another format, edited, cropped, or sent through a chat app that compressed it. To your eye the two look the same. To a computer they are two different files.

What a checksum shows

A checksum (also called a hash) is a short string of letters and numbers calculated from every byte of a file. The Digital Preservation Coalition calls it a digital fingerprint, and says the smallest change to the file makes the checksum change completely (DPC Handbook, Fixity and checksums). A post on the Library of Congress's blog shows two copies of one image that look identical; two bits were flipped in one, and the two checksums are entirely different (The Signal, Protect Your Data). Principle

Two things follow, and the second is our inference from those two sources rather than a sentence either one says. First, two files with the same checksum are exact copies. Second, a resized or re-saved copy has a different checksum, so a tool that compares checksums finds only exact copies and misses every near duplicate. Principle That is why exact copies are the easy case. They can be removed with no judgment about quality, because both copies are the same. Near duplicates need a person to look.

File names are not a test

Phones and cameras number their files, and the numbers repeat. Two phones can each make a file called IMG_0412 that shows two different photos. And the same photo can arrive under two names, one from the camera and one from a chat app or an export. Deciding by name alone would delete different photos and keep copies of the same one. Compare the picture, the date and the size, not the name.

Which copy to keep

The Library of Congress's advice on personal photos says that where there are several versions of an important photo, you save the one with the highest quality (Library of Congress, Keeping Personal Digital Photographs). "Highest quality" is not one number. In practice it means the copy closest to what the camera first saved, with everything you have added to it.

The usual poorest copy

A copy that came through a chat app is usually the poorest of a set. A 2025 study that sent photos by USB, email and several messaging apps found that chat transfers in image mode removed metadata through compression, while USB and email kept every field (Soni, Perspectives in Legal and Forensic Sciences; we read the abstract only). WhatsApp offers Standard and HD quality for each photo you send, and its help page says you cannot upgrade a photo once it is sent; you send it again in HD. It does not give the pixel sizes of either. Product-specific

A copy made by Google Photos' Storage saver setting is also reduced. Google says Storage saver resizes photos larger than 16 megapixels to 16 megapixels and may convert them to a different format, such as JPEG (Google Photos Help, backup quality). If the same photo exists as a Storage saver copy in the cloud and as the original on an old phone, the phone's copy is the one to keep.

Where to see the size

On an iPhone in iOS 27, open the photo and swipe up, or tap the Info button: Apple lists the capturing device, the date and time, and camera details such as file size (Apple's iPhone guide, photo information). On a computer, the file's properties or info window shows the size and, for most photos, the pixel dimensions. If you cannot see the details, compare the two copies zoomed in on the same area: a resized copy goes soft sooner.

When you cannot tell

If two copies look equal and the details do not settle it, keep both. Space is cheaper than a lost original, and the rest of the year still gets cleared. This manual's rule Write your own rule on the plan sheet's "Duplicates rule" line, in your words, for example: "keep the largest copy with the original date; chat copies go once the original is found; when unsure, keep both" (Library plan).

The duplicate tools in photo apps

Each photo app handles duplicates its own way, and the makers say different amounts about how. The table gives what each maker's help page says, as of 2026-10-30.

Sources: Apple, Merge duplicate photos on iPhone; Apple, Remove duplicates on Mac; Google Photos Help, photo stacks; Microsoft, Manage photos with the Photos app. Product-specific

Apple's Duplicates collection

Apple's tool merges rather than deletes. On a Mac, Apple says one original appears where the duplicates were, and the merged-away copies go to Recently Deleted, where you can recover them within 30 days. Apple does not say how Photos decides that two items are duplicates, or which copy's date, caption or album membership is kept when they merge. So the tool's choice is a suggestion to check, not a verdict. Open a few sets before you merge them all, and after the merge open the result and check that the date and caption are the ones you expected.

Two Apple facts bear on safety. With iCloud Photos on, a merge or a delete on one device happens on every device signed in to the same Apple Account. And Apple's iCloud storage page says that if you are over your iCloud storage limit, deleted photos are removed at once, with no stay in Recently Deleted (Apple, Manage your iCloud storage). Check that you are under your limit before you merge. If you are over it, make the backup first and expect no 30-day window.

Google Photos

Google's help pages describe no duplicate finder. The stacking feature puts similar shots in one stack with a Top pick on top, in the app, for backed-up photos only; Google says it does not change your storage. A stack can help you spot a set of near duplicates, but it removes nothing, and its Top pick is the app's choice, not a quality check. For a Google library, sort a year by date and compare neighbors by eye. When you delete in the Google Photos app, the item goes to Trash for 30 days, and Google says deleting in the app also deletes the copy on your device (Choosing what to keep explains this in full).

Folders on a computer

In a folder, sort by date taken (or by name, if the camera's numbering is intact) and look at neighbors. Exact copies from a second import may sit side by side with the same size, sometimes with "(1)" or "copy" added to the name. Delete into the computer's trash or recycle bin, and leave the trash alone until the count is checked.

Apps sold to find duplicates exist for every system. This manual does not recommend one. If you use one, the rest of this chapter still applies: a copy first, a sample checked by eye, counts before and after, and nothing emptied from the trash until the counts agree. This manual's rule

Merging one year, one folder or two libraries

Work on one year or one folder at a time. A year is small enough to check by eye and large enough to matter, and a mistake stays inside it.

Before you start: the way back

A recovery window is the time a deleted item can still be brought back: 30 days in Apple's Recently Deleted and in Google Photos' Trash. A recovery window is a safety net, not a backup. It empties itself on a date, it can be skipped (Apple's over-the-limit rule), and it holds only what this app deleted. Before a merge, make one of these true:

• A backup of the library exists, and its date is earlier than today. Backups sets one up.
• Or you export that year's originals to a drive first. On an iPhone in iOS 27, Apple's guide gives Share, then Export Unmodified Original, then the drive under Locations (Apple's iPhone guide, import and export).

Write the backup's date or the export's date on the inventory row before you merge. That date is what makes the merge safe to repeat next month.

Merging within one library

1. Count before. Write the number of items in the year or folder. Apps show this in different places; if yours shows a count when you select all of a year's items, use that, and check your own app if not.
2. Find the sets. Use the Duplicates collection, or sort by date and look.
3. Check five sets by eye. For each, decide which copy you would keep by the table in which copy to keep, and see whether the app's choice agrees.
4. Merge or delete the rest. If the app's choices agreed on all five, merge the year. If not, merge set by set.
5. Count after, and explain the difference. The count before minus the count after should equal the number of copies removed, and those copies should be sitting in Recently Deleted or Trash.
6. Write the row. On the inventory: the year or folder, both counts, the date, and the backup's date.

Merging two libraries

Combining two libraries, for example an old laptop's folders and a phone's cloud library, follows the same idea with one more decision: which library is the base, the one the other is brought into. Use the larger library with the better copies as the base. It is usually the one set to keep originals, which One home for your photos settles. Then:

1. Count both. Write the count of the base and of the incoming library.
2. Bring the incoming library in as a copy, with the source left untouched (Getting photos out).
3. Check the arithmetic. Right after the import, the base should hold its old count plus the incoming count. If an app skips items it recognizes as already present, note how many it skipped.
4. Remove duplicates one year at a time, as above.
5. Write the final count. It should equal the two counts added together, minus the skipped items, minus the copies removed. Any other gap is a question to answer before the incoming library's source is wiped.

See it: Nadia and the Okafors See it

Free pages that show the tools and the idea:

• Apple's iPhone guide, Merge duplicate photos and videos: the Duplicates collection path in iOS 27, in four short steps.
• Apple's Photos guide for Mac, Remove duplicates: where merged copies go and how long they stay.
• The Library of Congress's Signal blog on file fixity: two identical-looking images with different checksums.
• Google Photos Help on photo stacks: what stacking groups, and that it frees no storage.

Practice: merge one year Practice

Minimum: one year or one folder, five sets checked by eye, the count before and after on the inventory, and a backup or export dated before the merge. Time: about an hour; longer for a year with many chat copies. Materials: the phone or computer that holds the library, a backup or a drive to export to, the inventory and the library plan.

1. Pick the year. A year with a known source of copies (a chat group, a second phone, a second import) shows the most.
2. Make the way back. Note your latest backup's date, or export the year's originals to a drive. Check that your cloud account is under its storage limit.
3. Count before. Write the count on a new inventory row for the year.
4. Find and check five sets. Use the duplicate tool or sort by date. For each set, write which copy you would keep and why: pixels, format, date.
5. Merge or delete. Leave Recently Deleted or Trash alone.
6. Count after and explain the difference. Write it on the row with the date.
7. Write your duplicates rule on the plan sheet in one or two sentences.

Your photos Your photos

Check your work Check your work

Criteria

• Does the inventory show the year or folder, the count before and after, and the date of the merge?
• Is there a backup or export dated before the merge, and is its date written down?
• Can you explain the difference between the two counts as copies removed?
• For the five sets you checked, did the copy you kept have the most pixels, the original format and the original date?
• Are pairs that belong together (Live Photos, raw and JPEG, sidecars, scan masters and their sharing copies) still together?
• Does the plan sheet have a duplicates rule in your own words?

Worked example

Nadia's row names the year Theo was born, both counts, the date, the date of the drive export, and "WhatsApp copies of my own photos removed; Lila's kept". The difference between her counts matches what sits in Recently Deleted. Her plan sheet reads: "Keep the largest copy with the original date; chat copies go once the original is found; when unsure, keep both." It passes. It does not say every duplicate in her library is gone, because she has done one year.

Common mistakes

• Merging the whole library at once. A mistake then spreads across every year. Work a year at a time.
• Trusting the app's choice without looking. Apple does not say which copy's details survive. Check five sets first.
• Keeping the chat copy because it was the one with a caption. Move the caption to the original first, then remove the chat copy.
• Deleting by file name. Names repeat across phones. Compare the picture, the date and the size.
• Splitting a pair. Deleting a Live Photo's video, a raw file's JPEG or an XMP sidecar removes part of one photo.
• Emptying Recently Deleted or Trash the same day. Leave the recovery window to run until the counts are checked and the backup has caught up.
• Merging while over the iCloud limit. Apple removes deleted photos at once in that case. Make the backup first.

What is still unresolved

The other years still have their duplicates; each takes the same steps. Which of two different photos of one moment to keep is a choice Choosing what to keep covers. Whether the backup that made this safe works is settled by opening a photo from it, in Backups. Where a chat copy is the only copy you hold, the original is on the sender's phone, and only the sender can send it.

Knowledge check and scenario

Checklist

• One year or folder is merged, with the count before and after on the inventory and a backup or export dated before the merge.
• I checked five sets by eye and kept the larger, original copy of each.
• The plan sheet has my duplicates rule.
• I merged two libraries and wrote the arithmetic on the inventory. (Go deeper; optional)