Remove Metadata From the Terminal on macOS

The ones worth memorizing. Each is explained below.

On the test file it removed everything identifying and took 8,226 bytes off, 611,419 down to 603,193. The image data was untouched.

By default exiftool keeps a backup next to the file. Running -all= without -overwrite_original left photo.jpg at 603,193 bytes and photo.jpg_original at the full 611,419. Useful while you are learning, and a surprise when you discover 400 of them in a folder six months later.

-gps:all= is the command people reach for when they only care about location, and it is worse advice than it looks. It removed all 14 GPS tags from the file used in our EXIF removal guide and left the IPTC sub-location, province, country, the XMP equivalents and the camera body serial number sitting in place. Location is stored in more than one vocabulary. Delete all of them.

exiftool tells you about the first problem itself, every time: Warning: ICC_Profile deleted. Image colors may be affected. If the photo was tagged Display P3 or Adobe RGB and you delete the profile, viewers fall back to sRGB and the colors shift.

The fix is to copy selected tags back from the file itself. @ means “this same file”:

exiftool -overwrite_original -all= -tagsfromfile @ -icc_profile photo.jpg

Verified: 25 of 25 ICC tags kept, 0 EXIF tags, 0 GPS, 0 IPTC, 0 XMP. Orientation is the other one worth rescuing, because deleting EXIF on a portrait-orientation photo makes it display sideways:

exiftool -overwrite_original -all= \
  -tagsfromfile @ -Orientation -icc_profile photo.jpg

Verified on a file tagged Rotate 90 CW: the orientation came through unchanged, all 25 ICC tags survived, and exactly two EXIF tags remained, Orientation and YCbCrPositioning. Neither identifies anything. exiftool still prints the ICC warning on this command even though the profile is restored a moment later, so ignore it here.

On macOS this is not a detail. -overwrite_original writes a new file and renames it over the old one, which silently drops every extended attribute. That includes your Finder tags and the “Where from” URL Safari records on downloads.

We tagged a copy Red and Confidential, gave it a download URL, and ran both flags. The inode numbers tell the story:

Both removed all 39 EXIF tags. Which one you want depends on why you are stripping. Cleaning a file before you send it out? -overwrite_original is doing you a favor, because kMDItemWhereFroms can contain a full internal URL including the folder name it came from. Reorganizing your own archive and you rely on Finder tags? -overwrite_original_in_place and nothing else.

To clear extended attributes deliberately, xattr -c file.jpg. That left only com.apple.provenance behind on macOS 27, which the system manages and you cannot remove.

Writing to a file updates its modification date, which reorders your Finder window and confuses every backup tool you own. -P prevents it.

exiftool -overwrite_original -P -all= photo.jpg

Verified on a file whose modification date was set to 2020-01-02 03:04:05. Without -P, it became the time the command ran. With -P, it stayed at 2020-01-02 03:04:05.

The reverse problem is more common and more annoying. You copied photos off a card or out of a cloud folder and every file now claims it was created today, so they sort wrong. The capture time is still in the EXIF, so put it back:

exiftool -overwrite_original \
  "-FileModifyDate<DateTimeOriginal" \
  "-FileCreateDate<DateTimeOriginal" \
  -r -ext jpg -ext heic ~/Pictures/import/

Verified: a file showing both dates as 2026-09-26 12:00:00 came out with modification and creation both at 2020-01-02 03:04:05, the capture time in its EXIF. The quotes are required, because the shell will otherwise read < as a redirect and give you a spectacularly confusing error.

Do this before you strip the metadata. Afterwards there is no DateTimeOriginal left to copy from.

-r recurses. -ext restricts by extension and can be repeated. -if filters on tag values. Together they let you be precise about a job you are not watching.

# only jpg and png, down the whole tree
exiftool -overwrite_original -all= -r -ext jpg -ext png ~/Desktop/outgoing/

# only files that actually have coordinates
exiftool -overwrite_original -gps:all= -r -if '$gpslatitude' ~/Desktop/outgoing/

The extension filter was verified on a tree holding two JPEGs, a PNG and a PDF: exiftool reported “3 directories scanned, 3 image files updated” and the PDF came through with all 15 of its tags intact. The condition was verified on a pair of files, one with GPS and one without: “1 files failed condition, 1 image files updated”.

Point it at the folder, never at a loop. One process over 90 mixed files took 4,030 ms; a shell loop calling exiftool once per file took 16,217 ms for the same result. The full comparison, including Automator and a Folder Action, is in batch-stripping a whole folder.

For long repeated invocations, put the flags in an argument file and pass -@:

cat > ~/strip.args <<'EOF'
-overwrite_original
-all=
-tagsfromfile
@
-icc_profile
-P
EOF

exiftool -@ ~/strip.args photo.jpg

Verified: 25 ICC tags kept, 0 EXIF. One argument per line, no quoting, no shell escaping to get wrong. This is also the cleanest thing to call from a Folder Action.

For mixed jobs in a single process, -execute separates command groups and -common_args applies flags to all of them:

exiftool -gps:all= one.jpg -execute -all= two.jpg -common_args -overwrite_original

Verified: one.jpg lost its 9 GPS tags and kept 30 other EXIF tags; two.jpg lost all of them. One interpreter startup for both.

exiftool’s default output hides duplicates, which is exactly the wrong behavior when you are auditing. -a shows all of them; -G1 labels the group each came from.

exiftool -a -G1 photo.jpg

On a PDF the difference is not cosmetic. The default listing showed 11 tags. Adding -a showed 15, because Title, Subject, Creator and Producer were present in both the Document Info dictionary and the XMP packet and exiftool was only printing one of each. Four real entries, invisible.

For a folder, export a table before and after:

exiftool -csv -r -GPSLatitude -GPSLongitude -DateTimeOriginal \
  -Model -SerialNumber -Artist ~/Desktop/outgoing/ > before.csv

That took 543 ms for 90 files and showed 75 of them carrying a GPS latitude. Opens in Numbers, sorts, and gives you something to show someone who asks what was in the batch.

Two more reads worth knowing. exiftool -b -ThumbnailImage photo.jpg > thumb.jpg pulls the embedded preview out as a real file; on the test image that was a 2,997-byte 160 × 120 JPEG. And -fast2 skips trailing metadata when reading large files, though on our 90-file, 30 MB corpus it made no reliable difference: plain reads took 444 to 489 ms and -fast2 took 403 to 477 ms, which is noise. It pays off on multi-gigabyte video, not on a photo folder.

Four places. None of them are secret, and three of them are documented in its own manual.

PDFs are the big one. exiftool never deletes from a PDF, it appends an update. Its manual says so directly: “Changes to PDF files by ExifTool are reversible (by deleting the update with -PDF-update:all=) because the original information is never actually deleted from the file. So ExifTool alone may not be used to securely edit metadata in PDF files.” We tested it. One command restored all 10 Document Info keys and 12 XMP tags to a file cleaned seconds earlier. The fix is a rewrite afterwards:

exiftool -overwrite_original -all= document.pdf
qpdf --linearize document.pdf document-clean.pdf

That produced 155,649 bytes and a recovery attempt returned “Error: File contains no previous ExifTool update”. The long version, including what happens to comment authors and attachments, is in removing metadata from a PDF on Mac.

HEIC color profiles survive. exiftool prints its ICC warning on every HEIC and then leaves all 25 ICC tags in the container. Nothing identifying is exposed, but the message is wrong.

Video keeps a container date. On an MP4, -all= removed title, artist, comment, GPS position and the shooting-location record, and left the QuickTime CreateDate reading 2020:01:02 03:04:05. It is in the movie header rather than a metadata atom. If that matters, remux: ffmpeg -i in.mp4 -map_metadata -1 -c copy out.mp4, which in testing left nothing but ffmpeg’s own encoder string.

Extended attributes are invisible to it. Finder tags, Spotlight comments and the “Where from” URL live beside the file, not in it. xattr -c, or -overwrite_original, which drops them as a side effect.

If you got this far, you do not need our app, and we would rather say that than dress it up. exiftool is free, it is the reference implementation, it is faster than every drop target including ours, and it can edit metadata as well as delete it, which we cannot do at all. If you need to fix a wrong capture date across a shoot or write a copyright line into 400 files, exiftool is the only serious answer.

We will also point out the thing nobody in this market admits: our strip-metadata operation is exiftool. Run smol_doctor through the app’s tool surface and it is listed among the bundled binaries, and on a single JPEG our output has been measured byte-identical to exiftool -all=, SHA-256 and all. One exiftool process over a folder of 90 files beat our app by 3.8× and handled 10 files ours refused.

Buying Smol buys three things exiftool does not offer:

• A Finder right-click and a watched folder, so it happens without anyone typing anything.
• Originals preserved automatically, instead of remembering which overwrite flag you meant.
• Stripping, compressing and converting in one drop, for people who will not install Homebrew.

That is $29 once for convenience and delegation, not for capability. If you are comfortable in a shell, bookmark this page and keep the $29.

Related reading: what EXIF data actually contains, whether compressing a file removes its metadata, and our help article on removing EXIF and GPS data.