Organizing photos and videos: what it does and where it breaks down

Two systems are usually running at once on a Mac that holds a lot of photos and video. One is the Photos library, a database that happens to contain files. The other is everything sitting loose in folders: exports, screen recordings, footage handed over by someone else, card dumps that were copied across once and never touched again. The two were designed around opposite assumptions, and most of the time lost to searching comes from treating them as one thing.

The same phrase covers two different systems

The Photos library is a single package in the Pictures folder, with a .photoslibrary extension. Finder shows it as one item. Inside it is a database, and the database is what holds dates, locations, faces, albums, and keywords. Filenames inside a managed library carry almost no meaning, because nothing reads them. That is the design, and it works: a library can hold tens of thousands of items and still answer a question like "beach, last summer" without any naming discipline at all.

Loose folders are the opposite. Nothing keeps an index of them beyond Spotlight, so position and name are the only two things that distinguish one file from another. A file named Screen Recording 2026-04-11 at 15.03.22.mov sitting in Downloads is fully described by those two facts and nothing else.

The stall happens because both systems are in use simultaneously, usually without a decision ever having been made. Photos taken with a phone flow into the library. Everything received, exported, or recorded lands in folders. Each half has its own search box, and neither box sees the other half. Most "it should be here and it is not" moments are a search run against the wrong half.

Question	Photos library	Loose folders
What distinguishes items	database attributes	name and path
What the filename does	almost nothing	everything
Batch operations	limited to what the app exposes	anything scriptable
Access from other apps	requires an export	direct
Recovery unit	the whole library	one file

Counting problems and size problems are not the same problem

Grouping photos and video together hides the fact that they fail in different directions.

Photos fail by count. Each one is small, so several thousand of them add up to a manageable amount of disk. What breaks is human review. Screenshots are the clearest case: each was taken for a reason that lasted about an hour, and a folder of four hundred of them cannot be sorted by looking. The fix is not compression. The fix is a rule that decides what can be deleted without being looked at.

Video fails by size. The count stays small while each item is hundreds or thousands of times larger than a photo. Screen recordings and high resolution footage reach gigabytes in minutes. Reducing the number of files does nothing here. What works is moving the archive off the working disk and refusing to keep intermediate renders.

Which failure is in play can be measured in under a minute. Run du -sh * in the folder to get total size per item, and ls | wc -l to get the count. If video dominates the size list, it is a size problem. If the count is large but the total is modest, it is a count problem. When both are true, deal with size first, because clearing disk space is what makes the rest of the work possible.

du -sh ~/Downloads/* | sort -h | tail -20
ls ~/Desktop | wc -l

Every file carries three dates, and sorting picks one

Dates are where organisation quietly falls apart, because a single file has at least three of them and they disagree.

The capture time lives inside the file, in EXIF for stills and in container metadata for video. It is the only date tied to the content. The creation date records when the file appeared on this disk. The modification date records when its bytes last changed.

Copying or exporting rewrites the second and the third. A photo taken three years ago and exported this morning has today's creation date. Sorting a folder by date in Finder and seeing old material at the top is not a bug in the sort. It is the sort working correctly on a date that has nothing to do with when the shutter fired.

mdls -name kMDItemContentCreationDate \
     -name kMDItemFSCreationDate \
     -name kMDItemFSContentChangeDate IMG_1234.HEIC

Some files return nothing for capture time. Screenshots and screen recordings never passed through a camera, so no such field exists. For those, the only reliable date is the one macOS writes into the filename. That means one folder can hold files whose truth lives in metadata next to files whose truth lives in the name, which is exactly why a single sort rule never behaves consistently across the whole folder.

One row in Finder is not always one file

What Finder displays as a single item is not always a single item, and the difference only surfaces once a batch operation runs.

A Live Photo is a still plus a short clip. Depending on how it leaves the library, it arrives as a HEIC and a MOV with matching stems. Move one and the other becomes an orphan. Shooting RAW with JPEG produces the same shape: two files, one stem, two extensions. A deduplication rule written around filenames will read that pair as a duplicate and delete half of a deliberate pair.

Formats matter for the same reason. The default capture formats on recent iPhones are HEIC for stills and HEVC for video, both chosen for size at the cost of compatibility with older software. ProRes goes the other way, trading size for editing headroom, which is why a folder of edit masters and a folder of delivered files can differ by an order of magnitude while both are called video.

So the real content of this subject is not sorting. It is deciding what counts as one unit. Pairs move as pairs, or one side gets dropped on purpose. Deciding after running the batch is not possible, because the batch has already run. Replacing mv with echo and reading the output first turns an irreversible operation into a list that can be checked.

Duplicates that are not duplicates, and copies that are not copies

Two entries that look identical are sometimes one stored thing, and two entries that look different are sometimes the same bytes.

Importing into Photos copies the file into the library by default. Leave the original in place and there are genuinely two copies on disk. Meanwhile, duplicating a file on an APFS volume with cp -c creates a clone, and a clone shares storage with its source until one of them changes. Finder reports two files of full size; the free space on the disk barely moves. Running man cp on any Mac states this directly: -c copies using clonefile, and falls back to a normal copy only when the destination is on another filesystem or cannot clone.

Names and sizes are therefore weak evidence. Content hashes are strong evidence. If shasum -a 256 returns the same value for two files, the bytes are identical regardless of name or extension.

find ~/Pictures -type f -name '*.jpg' -exec shasum -a 256 {} + | sort | uniq -w64 -d

The file on this Mac may be a placeholder

Photos offers to keep full resolution originals in iCloud and hold only a lightweight version locally.

Store full-resolution photos and videos in iCloud. Source: support.apple.com

With that setting on, reaching into the library package from outside can find something much smaller than expected, or find nothing usable at all. A batch job that produces wrong dimensions or stalls partway through is often hitting placeholders rather than originals. iCloud Drive has an equivalent behaviour for documents, evicting files that have not been opened recently. Finder marks these with a cloud icon. A shell script sees a path that exists and content that will not read without a download first.

External drives create the same class of problem from a different direction. Material moved to an external volume is unreachable while the drive is unplugged, and Spotlight does not always index external volumes, which is why a file can be present and still absent from a Finder search. Any organising scheme has to state which material is expected to be online at all times. A volume that is connected twice a month is an archive, not a working folder.

Where the index stops and where it starts again

Spotlight is the layer that makes loose folders searchable at all, and knowing what it does and does not cover explains a whole class of missing files.

The index records file names, paths, and a large set of metadata attributes that applications write. For media, that includes pixel dimensions, durations, codecs, and capture times when they exist. All of it is queryable without any additional software.

mdfind 'kMDItemPixelHeight > 2000 && kMDItemContentTypeTree == "public.image"'
mdfind -onlyin ~/Movies 'kMDItemDurationSeconds > 600'

What the index does not do is look inside the Photos library package. Items managed by Photos are reachable through that app and through its own search, not through a query like the ones above. This is the mechanical reason the two systems described earlier stay separate: they have separate indexes, and no amount of care with folder structure bridges them.

The index also has gaps that are easy to mistake for missing files. External volumes are not always indexed, and a volume can carry an index that was never built. Folders excluded in Spotlight settings return nothing regardless of contents. Material downloaded from iCloud on demand may be indexed by name while its content remains remote.

The practical move is to check whether the index covers a location before concluding something is gone. A query restricted to a specific folder with -onlyin that returns nothing, when the file is visibly present in that folder, is evidence about the index rather than evidence about the file.

Matching the symptom to the layer

Symptom	Layer	Decision required
Search returns nothing though the file exists	two systems in parallel	which one is primary
Disk keeps filling	size, driven by video	where the archive lives
Review never finishes	count, driven by stills	what can be deleted unseen
Sorting by date looks wrong	three competing dates	which date is authoritative
A batch left half of a pair behind	unit definition	how pairs are treated
Processing returns empty or tiny output	placeholders	what stays local

Published material from file manager projects points at the same seam. Feature pages for this category lead with folders, a terminal, and an AI assistant sharing one window, which is a direct response to the fact that looking at files and acting on files normally happen in two separate places. The specific capabilities are listed on Features, and the question of what happens while away from the desk, which changes where archives can sensibly live, is covered under From iPhone and iPad. Anyone still choosing a tool will get more out of Compared with other file managers than out of a feature checklist, because the differences between these apps are differences of emphasis rather than of capability.

What to change first

Pick the primary system, then write down which date is authoritative and what counts as one unit. Those three decisions turn the rest into mechanical work that a script can do. Tooling choices come after, and Atriens is one of several worth reading about once the decisions exist.