Why Your Photos Library Is the Biggest Thing on Your Mac

Across every category covered on this blog, Photos is usually the single largest one on a personal Mac — bigger than any developer cache, bigger than System Data, often bigger than everything else on the disk combined.

du -sh ~/Pictures/Photos\ Library.photoslibrary

What’s actually inside the package

Finder shows Photos Library.photoslibrary as one file, but it’s a package — right-click and Show Package Contents to see the real structure:

du -sh ~/Pictures/Photos\ Library.photoslibrary/*

• originals/ — every photo and video at full, unmodified resolution. This is usually 80%+ of the library’s total size, especially with 4K video from a recent iPhone.
• resources/ — Apple’s derived data: thumbnails at every size the UI needs, the on-device face recognition index, and edit history for any photo you’ve adjusted (kept separately from the original so edits stay non-destructive).
• database/ — the actual catalog: albums, tags, dates, which photo is where. Small relative to the rest, but the part that would actually hurt to lose — this is your organization, not your media.

iCloud Photos “Optimize Mac Storage” — what it really does

If you have iCloud Photos enabled, System Settings → Apple ID → iCloud → Photos offers “Optimize Mac Storage,” which keeps smaller, device-appropriate versions locally and downloads full originals on demand when you actually open a photo. This is the single biggest lever most people never pull:

# No shell equivalent — this is a toggle in System Settings, not a command.
# System Settings → [your name] → iCloud → Photos → Optimize Mac Storage

The trade-off: opening an old photo you haven’t viewed in a while triggers a download from iCloud, which needs an internet connection and takes a moment the first time. For most people this is invisible in daily use and reclaims tens of gigabytes immediately. It only works if your library is actually backed by iCloud Photos — if you’re not signed into iCloud Photos at all, everything stays local regardless of this setting, full stop.

What if you’re not using iCloud Photos

If your library is local-only — no iCloud sync, or iCloud switched off — there’s no “optimize” button, and the options are more manual:

Delete duplicates and near-duplicates. Photos’ own Utilities → Duplicates view (in recent macOS versions) surfaces exact and near-exact duplicate detection built into the app — burst-mode sequences and accidental double-imports are common contributors here.

Empty the Photos Trash. Deleting a photo inside the app moves it to a Recently Deleted album for 30 days before actually freeing space — same mechanic as the Finder Trash, same fix:

Album → Recently Deleted → Delete All, or wait out the 30 days.

Move the library, or export what you don’t need daily. Photos supports multiple libraries and external-drive storage for an archival library you rarely open, keeping only a working library locally. This is a bigger workflow change than anything else in this article, worth it only if you’ve already optimized everything above and are still tight on space.

What not to touch directly

Never edit files inside originals/ or resources/ by hand, and never delete anything inside the package outside the app itself — the database/ catalog tracks exact file paths and checksums for everything in originals/, and manual changes desync the catalog from reality in ways that can corrupt the library or make photos “disappear” from the app while the files are technically still on disk. Every legitimate way to reclaim space here goes through the Photos app itself or the iCloud optimization setting, never a rm command aimed inside the package.

Where this fits with the rest of your disk

Photos is arguably the one major storage category on a personal Mac that genuinely isn’t cache or cruft — it’s the actual thing you own. That’s why DevCruft, the free Mac app for developers we’re building, is being designed to treat it differently from everything else it scans: shown at true size, marked as “keep,” and never offered as a reclaim target the way DerivedData or a stale node_modules folder would be, because “this 88 GB is real and yours” is as useful a thing to know as “this 62 GB is a build cache you don’t need.” Join the waitlist to hear when it launches.

For the other large, non-cache thing worth knowing about on a Mac, see the iPhone backups guide — Photos syncing and local backups are often confused for each other but are entirely separate storage categories.