# What makes a Photos library so large

> A Photos library is a database with a file store attached, and most of its size is not your photographs. What each folder holds, why the library is larger than the sum of your pictures, and what you must never delete.

Canonical: https://bytesweep.app/blog/photos-library-size.html
Last updated: 2026-10-30

## Why your Photos library is twice the size of your photos

`Photos Library.photoslibrary` looks like a file and is a folder. Right-click it, choose Show Package Contents, and the reason it’s bigger than your pictures is right there: the originals are only part of it, and around them sit several sizes of derived image for every photo, rendered copies of your edits, a database and the results of Photos' own analysis.

- By [Shajeen Ahamed](https://bytesweep.app/about.html#author)
- Published 30 October 2026
- Last updated 30 October 2026
- 4 min read
- Part of [Duplicate file finder](https://bytesweep.app/duplicate-file-finder.html)
- [How we write](https://bytesweep.app/about.html#how-we-write)

Start by measuring your own:

```
du -sh ~/Pictures/Photos\ Library.photoslibrary
du -sh ~/Pictures/Photos\ Library.photoslibrary/* 2>/dev/null
```

*In a typical library the originals are well over half the package but nowhere near all of it; the rest is regenerable, and it still isn’t yours to delete from the Finder.*

### What each folder holds

| Folder | What it holds | Typical share |
| --- | --- | --- |
| `originals` | Your photos and videos as imported, untouched | 50–70% |
| `resources/derivatives` | Thumbnails and display-size renditions | 15–35% |
| `resources/renders` | Rendered results of edits, one per edited photo | 0–15% |
| `database` | The SQLite database, its indexes and the search index | 0.5–3 GB |
| `private` | Working data for Photos and its background analysis | from small to several GB |
| `scopes` | Data for shared albums, the Shared Library and Shared with You | usually small |

The derivatives are the part people don’t expect. Photos keeps several sizes of every image so that scrolling through tens of thousands of pictures is instant. That’s a good trade, and it’s the main reason the package is always noticeably bigger than the originals alone.

Live Photos add up too. Each one is a still plus a short movie, both stored in `originals`, so it takes noticeably more room than an ordinary photo, which matters across thousands of them.

### Edits keep the original and a rendered copy

Edit a photo in Photos and the original isn’t touched. Photos stores the adjustments plus a rendered result. So an edited 5 MB HEIC becomes the 5 MB original plus a full-size render, which can easily be larger, and reverting to the original doesn’t necessarily remove the render straight away.

That’s what makes Revert to Original work years later, so I wouldn’t call it a flaw. It does mean a heavily edited library can be much bigger than what you imported.

### Nothing inside the package is yours to delete

Do not delete, move or rename anything inside the package. The database is the record of what exists, and the files serve it. Removing a file from `originals` doesn’t remove the photo from your library; it leaves a photo that won’t open and a library that fails verification.

That includes derivatives. Delete them to save space and Photos regenerates them, slowly, as you scroll, so the space comes straight back. Some versions leave missing-thumbnail placeholders behind as well.

It also includes deduplication tools pointed at `~/Pictures`. A perceptual matcher will happily report that `originals/0/034DD8F7-….heic` and `resources/derivatives/0/034DD8F7-…_1_105_c.jpeg` are the same picture. They are, and acting on it breaks the library. [Why similar-photo detection needs review rather than automation](https://bytesweep.app/blog/duplicate-photos-vs-similar.html) covers the general version of this hazard.

### Getting space back the supported way

In rough order of how much they return.

Empty Recently Deleted. Photos holds deleted items for about thirty days, and until that album is emptied nothing you deleted has freed anything. Open Recently Deleted in the sidebar and choose Delete All.

Turn on iCloud Photos with Optimise Mac Storage. Full-resolution originals move to iCloud and smaller versions stay on the Mac. It’s the biggest lever by far and it has a real consequence: those originals then exist only in iCloud, not in your Time Machine backup. [What Optimise Mac Storage keeps locally](https://bytesweep.app/blog/icloud-optimise-storage.html) covers the trade. It also explains why the local library can be bigger than your iCloud Photos usage: iCloud stores originals, while the Mac stores originals plus derivatives, renders and indexes.

Use the Duplicates album. Photos builds it itself and it understands the database. It catches most photos imported twice and many format pairs.

Clear out the loose copies outside the library. This is usually where the easy gigabytes are: exports in Downloads, an old import folder kept just in case, AirDropped or emailed JPEGs of pictures already in the library. [HEIC and JPEG pairs](https://bytesweep.app/blog/heic-jpeg-duplicates.html) explains where most of those came from.

### When the library itself is in a bad state

If a library has been mistreated, or an import died halfway, use the built-in repair. Hold Command and Option while opening Photos and it offers to repair the library. It checks the database against the files and rebuilds what it needs to, which can take a long time on a large library. It’s the supported fix, and it beats trying to reason about the contents by hand.

Back the package up before you run it. It’s a directory, so `rsync -a` to an external drive works.

### Questions

#### Can I move the library to an external drive?

Yes. Quit Photos, copy the package to the drive, then open it by holding Option while launching Photos and choosing it. To keep it syncing with iCloud Photos, make it the System Photo Library in Photos settings, under General. The drive has to be connected whenever Photos runs, and it should be formatted APFS or Mac OS Extended.

#### Does deleting derivatives free space permanently?

No. They regenerate on demand, so you get the space back only until you scroll through the library again.

### See all of this on your own disk

Every path on this page is one Bytesweep already knows by name. It measures the whole disk in about ten seconds, shows what is safe and what is not before you touch it, and moves everything it removes to a restore point you can undo for seven days.

[Download Bytesweep free](https://bytesweep.app/download.html) [Buy · $29.99](https://bytesweep.app/pricing.html)

### Keep reading

- [**HEIC and JPEG pairs are quietly doubling your photo library** macOS and iOS convert HEIC to JPEG whenever you share, export or edit in an app that cannot read HEIC, and keep both. Where the copies come from, how to find them, and which one to keep.](https://bytesweep.app/blog/heic-jpeg-duplicates.html)
- [**Duplicate photos and similar photos are different problems** A hash finds exact copies and nothing else. Perceptual comparison finds the burst shots, re-saves and resized exports that actually fill a photo library, with a false-positive rate you have to manage.](https://bytesweep.app/blog/duplicate-photos-vs-similar.html)
- [**What “Optimise Mac Storage” really does to your files** The iCloud setting that quietly evicts your files to the cloud, the rules macOS uses to choose them, why it often frees nothing when you need it to, and how to tell what is actually on your disk.](https://bytesweep.app/blog/icloud-optimise-storage.html)
- [**Finding duplicate files on a Mac without installing anything** Duplicates are found by size, then by hash, then by eye — in that order, because each stage is cheaper than the next. The shell commands that do it, what they miss, and the rules that stop you deleting the wrong copy.](https://bytesweep.app/blog/find-duplicate-files-mac.html)