Batch-Strip Metadata From a Whole Folder on Mac

Three runs each, corpus rebuilt from scratch before every run, median reported. All 90 files, all six formats, in one pass.

One exiftool process is roughly 3.8 times faster than our app on this corpus, and it handled ten files our app refused. If speed is your only criterion, stop reading and use the command.

The find rows are worth knowing because both forms get recommended interchangeably and one is four times slower than the other. -exec … + batches paths into as few invocations as the argument limit allows. -exec … \; runs the command once per file. Same tool, same result, 20 seconds of difference.

Before deleting anything across ninety files, find out what you are deleting. The whole point of a batch job is that you are not looking at the files individually, which is also the reason batch jobs quietly do the wrong thing.

# one line per file that still carries a GPS latitude
exiftool -r -q -q -if '$gpslatitude' -p '$filename' ~/Desktop/outgoing/

# a full inventory you can open in Numbers
exiftool -csv -r -GPSLatitude -GPSLongitude -DateTimeOriginal \
  -Model -SerialNumber -Artist ~/Desktop/outgoing/ > inventory.csv

On the test corpus that CSV took 543 ms for 90 rows, and 75 of the 90 files carried a GPS latitude. That included the video clips, which people rarely think to check. Here is what the folder held before and after the one-process run, counted as raw tags across every file:

Total bytes went from 32,002,385 to 31,237,805. Metadata was 764,580 bytes of the folder, about 2.4%. Batch stripping is a privacy operation, not a disk-space one.

exiftool is a Perl program. Every invocation loads the interpreter and then the tag tables for whichever formats it is about to touch, which is the expensive part. Give it a directory and it pays that once for ninety files. Call it ninety times and you pay it ninety times.

The gap is visible on a single file too. Stripping one JPEG directly took 149–207 ms, of which the actual work is a small fraction. Multiply the startup by your file count and the loop’s twelve extra seconds stop being mysterious.

# fast: one process, recursive, only the types you want
exiftool -overwrite_original -all= -r -ext jpg -ext heic -ext png ~/Desktop/outgoing/

# slow: ninety processes
for f in ~/Desktop/outgoing/*; do exiftool -overwrite_original -all= "$f"; done

The -ext filters matter more than they look. Pointed at a mixed folder with -ext jpg -ext png, exiftool reported “3 directories scanned, 3 image files updated” and left the PDF in the tree completely alone, all 15 of its tags intact. That is the flag that stops a batch job from touching things you did not mean to include.

If you want to keep the color profile, which you usually do for photographs, the flag set is in our exiftool reference for removing metadata. The short version is -all= -tagsfromfile @ -icc_profile.

A Folder Action turns “drop files here” into the same command. Build it in Automator: New › Folder Action, choose the folder at the top, add Run Shell Script, set the shell to /bin/zsh and Pass input to as arguments, then paste:

/opt/homebrew/bin/exiftool -overwrite_original -all= \
  -tagsfromfile @ -icc_profile -P "$@"

Use the full path. Folder Actions do not inherit your shell’s PATH, which is the single most common reason one silently does nothing.

We built exactly that workflow and ran it. On one 611,419-byte JPEG it produced 603,747 bytes with every EXIF, GPS, IPTC and XMP tag gone and all 25 ICC tags preserved. It works.

The cost is the wrapper, not the work. Each invocation took 634–852 ms against 149–207 ms for the same exiftool command run directly, so Automator is adding roughly half a second of startup every time the folder fires. Folder Actions trigger per batch of filesystem events, so a drop of ninety files at once pays that once, and ninety files arriving one at a time over a sync pays it ninety times. An AppleScript folder-action script is much cheaper if you want to write one: a warm osascript no-op measured 52 ms.

A drop-target app is the third option, and it is the one to reach for when someone else on the team has to do this and is never going to install Homebrew. We make Smol, which has a strip-metadata operation separate from compression, writes cleaned copies with a _metadata-removed suffix, and leaves your originals alone by default.

If your Mac is already driven by an AI coding agent, the same operation is exposed through our MCP server, so “strip the metadata from everything in ~/Desktop/release-assets and tell me which files had GPS in them” is one step inside Claude Code, Codex or Antigravity. That is genuinely useful when images get committed to a public repository on a schedule. It is overkill for one folder of holiday photos.

Three things, and the first one is ours. On the 90-file corpus our strip operation succeeded on 80 files and failed on 10, returning “This file couldn’t be processed. It may be corrupted or in an unsupported format” for every MP4 and every M4A.

The files were fine. The same app compressed both without complaint in a separate job. The strip operation covers images and PDFs; on our test it did not accept video or audio. If your folder is mixed, that is a real gap and exiftool does not have it: the same run cleared Title, Artist, Comment, GPS position and the shooting-location record out of every clip.

The second gap is HEIC color profiles. exiftool prints Warning: ICC_Profile deleted on every HEIC and then leaves all 25 ICC tags in place. Both tools do, because both are exiftool underneath. An ICC profile is not identifying, so this is a cosmetic inaccuracy in the warning rather than a leak, but it explains why a clean-looking folder still reports ICC tags afterwards.

The third is everything that is not inside the file. Filenames survive a metadata strip completely, and IMG_4471.HEIC or Contract_Klein_FINAL_v3.pdf can say more than the tags did. So do macOS extended attributes: the “Where from” URL on a downloaded file and any Finder tags you have applied. A metadata tool does not see them. Both are covered in our checklist for sharing photos safely.

For a folder, the honest numbers are not on our side. exiftool did 90 files in 4,030 ms. We did 80 files in 15,151 ms and refused the other ten. It is free, it is already the engine inside our strip operation, and on a single JPEG our output has been measured as byte-identical to its own.

Use the command line if you are comfortable there. Use exiftool -all= -r folder/, not a loop, and not -exec … \;.

Smol earns a place in a narrower set of situations:

• The people who need to do this will not open Terminal, ever, and a Finder right-click is the only instruction that will stick.
• You want the originals preserved automatically rather than remembering -o or -overwrite_original under time pressure.
• You are stripping, compressing and converting in the same drop, where three tools become one pass.
• You want a watched folder that cleans everything the moment it lands, without wiring up Automator yourself.

And two cases where neither belongs. Editing metadata rather than deleting it — fixing a wrong capture date across a shoot, writing a copyright line into 400 files — is exiftool territory and we do not compete there. A verified chain of custody for legal disclosure needs a documented procedure with hashes at each step, not a drop target.

Smol is $29 once. For single files, removing EXIF data on Mac compares six routes; for documents specifically, see removing metadata from a PDF, which is a genuinely different problem.