Organizing photos and videos: the setup order that holds up

Most attempts at organising a media library fail in the same way. An afternoon gets spent sorting a few thousand files into folders, the result looks good for about a week, and then new material lands in Downloads and the Desktop and the whole thing drifts back. The commands involved were never the problem. The sequence was. Sorting before naming means sorting twice. Naming before the inflow is under control means renaming forever. What follows is an order where each step makes the next one cheaper, and where stopping halfway still leaves things better than before.

Why the sequence matters more than the commands

Every step in this work produces an input for the next one. Deduplication is only reliable after copies have stopped multiplying. A naming rule is only worth applying once the dates behind it are trustworthy. Moving an archive to another volume only makes sense after the material worth archiving has been identified.

Doing these out of order is not merely inefficient. It actively destroys work. Files renamed before duplicates are removed leave two differently named copies of the same bytes, which makes them harder to detect afterwards. Folders created before the naming rule exists have to be rebuilt when the rule finally arrives. Material archived before the inflow is stopped starts filling the same disk again the following week.

The order below runs from the most upstream decision to the most downstream one. It is designed so that abandoning it after any step still leaves the library in a consistent state, which matters because this kind of work rarely gets finished in one sitting.

Step	What it decides	What breaks when skipped
Stop the inflow	where new material lands	the backlog regrows during the cleanup
Freeze the backlog	what is in scope	scope keeps expanding, work never ends
Set the naming rule	how a file is identified	folders get rebuilt later
Fix dates	what the names contain	sorting stays unreliable
Deduplicate	what is worth keeping	archive stores the same bytes twice
Split by size class	where material lives	the working disk fills again
Verify	whether the move succeeded	data loss is discovered months later

Stop the inflow first

Nothing downstream holds if new files keep arriving in six different places. The first action is to pick one landing folder and make everything point at it.

Three sources cover most cases. The browser download location is set in each browser's settings. Screenshots and screen recordings default to the Desktop, and that default is changeable from the Screenshot app's Options menu or from the command line. Camera imports land wherever Image Capture or Photos was last told to put them, and that choice sticks.

defaults write com.apple.screencapture location ~/Inbox
killall SystemUIServer

One inbox is enough. It will be untidy, and that is acceptable, because a single untidy folder is a tractable problem while six tidy ones are not. The goal at this stage is not order. The goal is that tomorrow's files all appear in a place that is known.

There is a second reason to redirect screenshots away from the Desktop specifically. Desktop items are drawn by the window server whether or not anything is looking at them, so a Desktop holding several hundred image files carries a cost beyond being hard to read. Moving them to a folder removes that cost immediately, before any sorting has happened at all.

AirDrop and messaging apps are the usual leaks after the obvious three are closed. AirDrop deposits into Downloads, which the redirect already covers. Attachments saved from mail and chat clients default to wherever they were last saved, so the fix there is behavioural rather than configurable: save into the inbox, every time, without deciding on a destination in the save dialog.

Worth resisting at this point is the urge to create the final folder structure. It does not exist yet, because the naming rule that justifies it has not been decided. Creating it now guarantees rework later.

Freeze the backlog before sorting it

The second step is to define what is being cleaned up, and then stop that definition from moving.

Create one folder with today's date in its name and move the existing scattered material into it, unsorted. Downloads, Desktop, the old folder from the previous cleanup attempt, the card dump from last year. Everything goes in, nothing gets examined yet.

mkdir -p ~/Archive/2026-09-11-backlog
mv ~/Downloads/* ~/Desktop/* ~/Archive/2026-09-11-backlog/ 2>/dev/null

This looks like avoidance and is the opposite. A frozen backlog has a fixed size, so progress through it is measurable and the work has an end. An unfrozen one grows while it is being processed, which is why previous attempts stalled. It also produces an immediate visible result, since Downloads and the Desktop are empty for the first time in years, and that clears the space needed to think.

The freeze has a second benefit. Anything not missed from that folder within a month is a strong candidate for deletion without review, and that judgement is only available because the material was moved as a block on a known date.

Decide the naming rule, then let dates fill it

Only now does naming become useful. A rule that holds up has three properties: it sorts correctly as plain text, it stays readable years later, and it can be generated by a machine rather than typed.

A date prefix in YYYY-MM-DD form satisfies the first, because text sorting and chronological sorting coincide. A short subject follows it. Anything beyond those two fields tends to be a field that should have been a folder.

The date must come from the content, not from the filesystem, because copying and exporting rewrite filesystem dates while capture time stays fixed inside the file.

mdls -name kMDItemContentCreationDate IMG_1234.HEIC
sips -g pixelWidth -g pixelHeight IMG_1234.HEIC

Screenshots and screen recordings have no capture time, since they never passed through a camera, but macOS writes the date into the filename at creation. For those, the name is the authoritative source and needs only reformatting.

Before any rename runs, print the result instead of performing it. Replacing mv with echo turns an irreversible batch into a list that can be read.

for f in *.HEIC; do
  d=$(mdls -raw -name kMDItemContentCreationDate "$f" | cut -c1-10)
  echo mv "$f" "${d}-${f}"
done

Reading that output once catches the two failures that matter: files where the date came back empty, and names that would collide. Both are cheap to fix on screen and expensive to fix after the fact.

Remove duplicates by content, not by name

With names stable, duplicates become findable. Filenames are unreliable evidence here in both directions. RAW and JPEG pairs share a stem while holding different content, and the same footage often exists under two unrelated names after being exported twice.

find ~/Archive -type f -exec shasum -a 256 {} + | sort | uniq -w64 -d

Identical hashes mean identical bytes, whatever the names say. The output lists the groups; deciding which member of each group survives is a separate pass, and the safe default is to keep the copy whose path already matches the naming rule.

One subtlety applies on APFS volumes. Files duplicated with cp -c are clones that share storage until one of them changes, so Finder shows two full-size items while the disk barely moved. Deleting one of those reclaims almost nothing, which is worth knowing before spending an hour on it. Genuine duplicates that arrived by download or export do free real space.

Live Photos and RAW plus JPEG pairs need an explicit decision before this step runs, not after. Either pairs move together as a unit, or one side is deliberately discarded. A deduplication pass that has not been told which of these applies will make the choice on its own.

Split by size class, then move the archive off the working disk

Stills and video fail differently, so they belong in different places. Stills accumulate by count and stay small in total. Video accumulates by size, with individual files reaching gigabytes after a few minutes of recording.

Measure before deciding, since the split is usually more lopsided than expected.

du -sh ~/Archive/* | sort -h | tail -20

Material that is finished moves to an external volume. Material still in use stays local. The test is not age but whether it is still being opened, and the frozen backlog folder from step two makes that easy to judge.

Copy rather than move, verify, and only then delete the source. rsync with -a preserves attributes and -n performs a dry run first.

rsync -an ~/Archive/video/ /Volumes/Archive/video/
rsync -a  ~/Archive/video/ /Volumes/Archive/video/

One caveat applies to any material held in Photos or iCloud Drive with optimised storage switched on. The local file may be a placeholder rather than the original, and a copy of a placeholder is not a copy of the photograph. Originals need downloading before the archive step, or the archive quietly contains thumbnails.

Filesystem format on the destination deserves one check as well. Drives sold preformatted for cross-platform use often arrive as exFAT, which does not preserve the extended attributes and resource forks that macOS attaches to files. For finished video that rarely matters. For material carrying tags, comments, or Finder colour labels, it silently drops the part that made the material findable. Reformatting as APFS or Mac OS Extended before the first copy avoids discovering this later, and ditto is the copy command that preserves macOS metadata when the destination supports it.

Verify, then keep it to ten minutes a week

Verification is the step most often skipped, and the only one whose absence stays invisible until the source is gone. Compare hashes on both sides before deleting anything.

find /Volumes/Archive/video -type f -exec shasum -a 256 {} + | awk '{print $1}' | sort > /tmp/dest.txt
find ~/Archive/video -type f -exec shasum -a 256 {} + | awk '{print $1}' | sort > /tmp/src.txt
comm -23 /tmp/src.txt /tmp/dest.txt

Empty output means every source file has a byte-identical twin on the destination. Any line printed is a file that did not arrive.

Comparing hashes rather than file counts matters because the two failure modes look different. A missing file shows up in a count. A truncated or partially written file does not, since it is present and has a name and a plausible size. Hashes catch both without needing to know which one happened.

One more check belongs here for archives that will sit untouched for years. A drive that has not been read in a long time can develop unreadable sectors that no software reports until something tries to read them. Running the same hash pass against the archive once or twice a year turns a silent failure into a line of output while a second copy still exists. Scheduling it is optional. Knowing that it is the only way the problem surfaces is not.

What keeps the result alive afterwards is a short recurring pass rather than another full cleanup. Once a week, empty the single inbox: apply the naming rule, send finished material to the archive, delete what was never going to be needed. Ten minutes is realistic because the inbox only holds one week of material and the rules were all decided months ago.

Tooling shortens that weekly pass considerably, since almost every action above involves looking at files and then acting on them, which normally means moving between two separate windows. What a file manager can do about that is listed under Features, the differences in emphasis between the available options are set out in Compared with other file managers, and the questions that come up before installing anything are answered in the FAQ.

What to change first

Set one inbox and freeze the backlog into a dated folder today, before deciding anything about names or folders. Those two actions take about fifteen minutes and make every later step smaller, and a tool such as Atriens is worth evaluating once the weekly pass is the only thing left to shorten.