How to Remove EXIF Data From Photos on Mac

Pick by what you have in front of you. The measurements behind each row are in the sections below.

No, and it never touches the file. Get Info’s editable fields, Tags and Comments, are stored as extended attributes on the filesystem, not inside the image.

Set a Finder comment and a tag on a copy of the test photo, then compare it to the original:

xattr photo.jpg
com.apple.metadata:_kMDItemUserTags
com.apple.metadata:kMDItemFinderComment
com.apple.provenance

cmp original.jpg photo.jpg   # no output: the two files are identical

The data fork is byte-identical. Finder wrote alongside the file, not into it. The practical consequences run both ways: stripping EXIF leaves your Finder tags in place, and clearing your Finder tags leaves the GPS coordinates in place.

Those attributes are also more portable than people expect. They survive cp and ditto. They are lost through a stream copy such as cat a.jpg > b.jpg, and through essentially every upload, because HTTP has nowhere to put them.

What Finder does know is more interesting than what it lets you delete. Spotlight parses EXIF at index time and stores the coordinates, so your Mac can already answer the question “which of my files are geotagged”:

mdls -name kMDItemLatitude -name kMDItemAcquisitionModel photo.jpg
kMDItemAcquisitionModel = "iPhone 16 Pro Max"
kMDItemLatitude         = 48.8584

# every geotagged file Spotlight knows about
mdfind -onlyin ~/Pictures -onlyin ~/Downloads 'kMDItemLatitude > -180'

That second command is the fastest audit on this page. Run it before you run anything else.

The GPS block. Nothing else. This is the single most misreported thing about Preview, so it is worth being exact.

Open an image in Preview, then Tools › Show Inspector (⌘I) and pick the metadata tab, or go straight there with Tools › Show Location Info. If the photo is geotagged you get a map and two buttons: Change Location Info and Remove Location Info.

That second button is scoped by its own name. Inside Preview’s app bundle, the inspector panel is defined in PVInspectorImageMetaData.nib, and the button labelled “Remove Location Info” is wired to the action removeGPSData:, sitting alongside keys called key_gps and data_gps. You can read that yourself:

strings -a "/System/Applications/Preview.app/Contents/Resources/Base.lproj/PVInspectorImageMetaData.nib" \
  | grep -iE "location|gps"

PVInspectorImageMetaDataGPSSplitViewPosition
Remove Location Info
data_gps
key_gps
removeGPSData:

So: coordinates gone, everything else staying. On our test file that would leave the camera body serial number 343037005264, the lens serial number, the exact capture time, the Lightroom version that processed it, the original RAW filename 20221115-EM4A0217.CR2, and three IPTC fields that spell out 7th arrondissement of Paris, Paris, France in plain text.

One caveat on method, since it applies to this route and the Photos one below. The file-level numbers in this article come from running the tool and hashing the output. Preview and Photos are GUI-only, so what is described here comes from their menus and their app bundles rather than from a before-and-after comparison of bytes. Where a claim is about scope rather than output, the evidence is named so you can check it.

For a photo you are sending to one person, that is often fine. For a photo going somewhere public it is not the same thing as removing metadata, and Preview does not claim otherwise. Preview also has no equivalent for documents at all: its own binary carries the string Metadata inspecting on PDF is not supported.

From the exported copy, yes, if you uncheck the right box. From your library, no, and that catches people out.

In Photos on macOS 27, File › Export › Export Photo gives you three metadata checkboxes. Their labels come straight out of IPXExportViewController.nib in the Photos app bundle:

• Title, Keywords, and Caption
• Location Information, bound internally to a property called includeLocation
• Export IPTC as XMP

Export Unmodified Original has no location checkbox, because there is nothing to decide. It hands you the file as it was imported, with whatever EXIF it arrived carrying.

The part worth internalising: Photos keeps location in its own database, not in your file. The library’s Photos.sqlite has ZLATITUDE, ZLONGITUDE and ZLOCATIONDATA columns on the asset table, plus reverse-geocoded place records in a second table. Because of that, an export can put a location into a file that did not have one. The Photos binary exposes a method literally named gpsDictionaryForLocation: and another called updateMetadataBuilder:withAsset:includeLocation:. That is export metadata built from the asset record, not copied from the source file.

That is a big enough topic that it has its own article: removing GPS location from photos on Mac covers the library, the iOS setting that stops it at source, and which platforms strip coordinates on upload.

Because sips is an image processor with a ColorSync profile editor bolted on, and its --deleteProperty flag belongs to the second half. It has no idea what an EXIF tag is.

Three commands, one file, measured:

Read that table twice. sips -d artist reports success, returns no error, makes the file 4.9% larger, and the Artist tag is still there afterwards. All three commands produce byte-identical output, because sips has exactly one write path and it runs regardless of what you asked for.

It is a genuine re-encode, not a rewrite. Comparing the JPEG’s entropy-coded scan data before and after gives two different hashes, and comparing the decoded pixels against the original gives an RMSE of 181.467 and a PSNR of 51.15 dB. You will not see that difference on screen. It is still a generation of quality you spent for nothing.

The one thing sips -d profile does do is remove the ICC profile, which is what the flag is for. It took the test file from 39 ICC tags to zero.

Two more sips results, because both are commonly assumed to clean a file and neither does. sips -Z 2000, the standard resize-for-email command, came out the other side with all 14 GPS tags at full precision. sips -s format heic carried all 14 across into the HEIC. Converting and resizing are not sanitising.

Install it with brew install exiftool. Then, for the common case:

# remove every metadata block, write to a new file
exiftool -all= -o clean.jpg photo.jpg

# same thing, in place, no backup copy
exiftool -overwrite_original -all= photo.jpg

# a whole folder in one process
exiftool -overwrite_original -all= ~/Desktop/photos/

On the test file, -all= removed everything except four structural markers:

File size went 7,573,756 → 7,521,929 bytes. Fifty-one kilobytes of metadata, which is 0.68% of the file.

Two traps. The first is that ICC line. exiftool prints Warning: ICC_Profile deleted. Image colors may be affected, and it means it. If the photo was tagged with anything other than sRGB, deleting the profile can shift how it renders. Keep it:

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

That produced 7,525,091 bytes on our file, kept all 39 ICC tags, and still removed everything identifying.

The second trap is more dangerous, and it is the reason the GPS-only command is bad advice. Running exiftool -gps:all= removed all 14 GPS tags from the test file. Here is what was still in it afterwards:

[IPTC]  Sub-location                : 7th arrondissement of Paris
[IPTC]  Province-State              : Paris
[IPTC]  Country-PrimaryLocationName : France
[XMP-photoshop] State               : Paris
[XMP-iptcCore]  Location            : 7th arrondissement of Paris
[ExifIFD] SerialNumber              : 343037005264
[XMP-crs] RawFileName               : 20221115-EM4A0217.CR2

The coordinates are gone and the file still names the neighbourhood. Location lives in more than one place, and -gps:all= only knows about one of them.

It means the JPEG’s compressed image data is never decoded, so it cannot lose quality. A JPEG file is a chain of marker segments: metadata blocks, then the quantization and Huffman tables, then one long run of entropy-coded bytes holding the actual picture. Metadata stripping deletes segments from the front. Re-encoding throws the picture away and makes a new one.

You can check which happened by hashing everything after the start-of-scan header. Those bytes are the image. On the test file, before and after:

Decoding both files to raw RGB and hashing that gives the same answer from the other direction: the three stripping routes produce pixel-for-pixel identical images, and sips does not.

The same holds outside JPEG. A PNG carrying a copied-in EXIF block went from 1,489,489 to 1,454,221 bytes with all 14 GPS tags removed and identical decoded pixels. A HEIC went from 4,449,052 to 4,445,962 bytes, also pixel-identical, with nothing left but container and codec structure: MajorBrand, HandlerType, HEVCConfigurationVersion and the rest of the HEVC parameter set.

If you do also want the file smaller, that is a different operation and it does re-encode, deliberately. Compressing the 1,600 px derivative at quality 75 took it from 790,878 to 249,185 bytes, a 68.5% reduction, with every metadata block removed in the same pass. The general question of what compression does and does not remove is covered in our guide to compressing images on Mac.

We make Smol, a Mac app that compresses and converts files locally, and it has a dedicated strip metadata operation that is separate from compression. Drop files in, and it writes cleaned copies next to them with a _metadata-removed suffix, leaving your originals where they were.

Fifty geotagged JPEGs, 39,827,924 bytes in total, went through it in 5,281 ms. It removed 2,721,600 bytes of metadata, 6.83% of the batch. Every output had zero GPS tags, and spot-checking four of them confirmed the scan data hash and the decoded pixels were unchanged.

Here is the part we will not dress up: on the single file, Smol’s output was byte-identical to exiftool -all=. Both produced 7,521,929 bytes. That is not a coincidence, and it is not a secret either. Run smol_doctor through the app’s tool surface and exiftool is listed among the bundled binaries. What you are paying for is the drop target, the Finder Quick Action, the watched folder, and not having to remember -overwrite_original. You are not paying for a better stripper, because there is no better stripper than the one everybody already uses.

It works the same way on documents. A 26-page PDF went in with Author, Title, Creator, Producer, Keywords, both timestamps and the full pdfTeX banner string, and came out with all of them gone and 26 pages intact. It also came out 260 bytes larger, because rewriting a PDF’s cross-reference table costs a little. If your work is mostly documents, compressing PDFs on Mac covers what the compression presets do and do not touch.

If you already drive your Mac through an AI coding agent, Smol ships an MCP server exposing the same strip operation as a callable tool, so “strip the metadata from everything in ~/Desktop/upload and tell me what was in them” runs as one step inside Claude Code, Codex or Antigravity. It is genuinely useful for release pipelines where images get committed to a public repo. It is overkill for one holiday photo.

For one photo, exiftool -all= is free, takes four seconds, and gives you the identical file. Use it. If you will not open Terminal, Preview’s Remove Location Info handles the case most people actually care about, also for free.

For a folder, the honest number is unflattering. The same 50 files that took Smol 5,281 ms took exiftool -overwrite_original -all= batch/ 465 ms. One exiftool process walking a directory is roughly eleven times faster than our app, and it is free. The trap people fall into is writing a shell loop instead, which pays Perl’s startup cost fifty times over: the same job as for f in *.jpg; do exiftool ... "$f"; done took 4,874 ms. If you are going to use the CLI, pass it the folder.

Smol earns its place in a narrower set of cases:

• You want a Finder right-click or a watched folder rather than a command you have to remember.
• You want the original left alone automatically, rather than remembering -o or -overwrite_original.
• You are stripping and compressing and converting in the same drop, where three tools become one.
• Someone else on your team has to do this and will not be installing Homebrew.

And three cases where nothing on this page is the right tool. If you need to edit metadata rather than delete it, whether that is fixing a wrong timestamp or writing a copyright line across a shoot, exiftool is the only serious option and Smol does not compete. If you need a verified audit trail for legal disclosure, you want a forensics workflow with hashes at every step, not a drop target. And if the photo is going somewhere public, metadata removal is table stakes rather than the finish line: current image-geolocation models read the pixels, and a clean file taken outside a recognisable building is still a located photo.

Smol is $29 once, and the step-by-step version of the workflow is in our help article on removing EXIF and GPS data. If you want to know what these tags actually are before you delete them, what EXIF data contains walks a real tag dump line by line.