ExifCleaner: a desktop batch metadata stripper built on ExifTool

The problem ExifCleaner solves, and who it is actually for

A JPEG straight out of a phone carries GPS coordinates, a device serial number, a timestamp and often a thumbnail of the original image. Stripping that by hand means knowing ExifTool's tag syntax, and ExifTool's documentation is written for people who already know what an IFD is. ExifCleaner exists to put a file list in front of that engine.

The target user is someone with a folder of files and no interest in the command line: a journalist preparing photos for publication, a seller uploading product shots, a developer scrubbing test fixtures before committing them. The README frames the intake as a verified allowlist of image, media and PDF extensions rather than ExifTool's full catalog, which is a deliberate narrowing. If your format is not on that list, the app will not touch it.

Two design choices tell you who this is not for. There are no automatic updates and no network traffic at all, so the app never phones home and never patches itself. And it is not code-signed. The README states the reason plainly: an Apple Developer certificate costs $99 a year and embeds the holder's legal name in the Gatekeeper dialog, while Windows wants an EV certificate at $200 to $600 a year tied to a verified legal identity. For a project maintained anonymously, the author declined that trade.

How the cleaning actually works: ExifTool in stay-open mode

ExifCleaner is an Electron app. The repository layout confirms the split: src/ for the application code, electron.vite.config.ts for the build, tests/ with vitest and playwright configs at the top level. The metadata work is not reimplemented in JavaScript. The app drives ExifTool, and the README names the mechanism: batch processing via ExifTool's stay-open protocol.

That detail matters more than it looks. ExifTool's normal invocation starts a Perl interpreter, loads its tag tables, processes files and exits. Doing that once per file in a 500-image batch means 500 interpreter startups. The stay-open protocol keeps one ExifTool process alive and feeds it work, which is where the batch speed comes from. The README attributes the speed to that protocol, not to any custom parsing.

The processing pipeline is visible in the interface. Files are added by drag and drop, including whole folders, and folder recursion is one of the privacy controls added in v4.0. Each file can be expanded to show a before/after diff of what was removed, which is the app's answer to the trust problem: you do not have to take the result on faith, you can read the removed tags. Four other controls sit alongside it: preserve orientation, save as copy, remove macOS extended attributes, and preserve timestamps. Those are the choices that decide whether a cleaned file is still usable, since stripping orientation can rotate a photo and stripping timestamps breaks chronological sorting.

Installing ExifCleaner on macOS, Windows and Linux

There is no package to build. The README points at the GitHub releases page for every platform, and explicitly warns that builds shared through other channels are not verified. macOS 12+, Windows 10+ and Linux are supported, 64-bit only.

On macOS you pick between two disk images, arm64 for Apple Silicon and the other for Intel. The README notes these are native builds with no Rosetta involved. Because the app is unsigned, first launch is blocked. On macOS 14 and earlier, right-click the app, choose Open, then click Open in the dialog. On macOS 15 and later that route no longer works: double-click once and let it be blocked, then go to System Settings, Privacy & Security, scroll down and click Open Anyway next to the ExifCleaner entry.

Windows offers a portable .exe, which the README recommends, or an installer. SmartScreen will show "Windows protected your PC"; click More info, then Run anyway. Linux users get .AppImage, .deb or .rpm. The README links to an external guide for making an AppImage executable.

Arch users have a shorter path through the AUR:

paru -S exifcleaner-bin

Whichever artifact you take, the release page carries a SHASUMS256.txt. Download it next to your file and check it:

sha256sum -c SHASUMS256.txt 2>&1 | grep OK

The README states that CI mounts the DMG, installs it, launches it and strips metadata from a test image before a release can publish, so the checksum verifies that what you downloaded is byte-for-byte what CI built. A first real use is a single folder: drag it onto the window, expand one file to inspect the before/after diff, confirm the tags you expected are gone, then let the batch run.

Where ExifCleaner cannot deliver a clean file

The README's limitations table is the most useful page in the project, because it draws a line between formats that work and formats that only appear to. Five cases are listed.

RAF files are refused before any write. ExifCleaner states it cannot currently guarantee a safe cleaned RAF artifact, so the source is left unchanged. That is the right call, but it means a Fujifilm shooter gets nothing.

PDF is the one to read carefully. ExifTool writes a reversible PDF update, so the original metadata remains recoverable in the file. ExifCleaner therefore cannot securely erase PDF metadata, and the README calls this a documented limitation tracked as issue #216. If your reason for cleaning a PDF is that a recipient must not recover the author or the producing application, this tool does not do that job. Redaction and flattening are different operations.

MKV is rejected at intake because ExifTool exposes Matroska metadata for reading but provides no writable tags. That is an upstream constraint, not an ExifCleaner bug, and no amount of app-side work fixes it.

TIFF removal may be partial because some metadata can remain in IFD0, tracked as an open investigation in issue #199. AVIF has a user-reported partial-removal case also under investigation as issue #215. Both are described as unresolved, so treat TIFF and AVIF output as needing your own verification rather than as guaranteed clean.

ExifCleaner versus ExifTool on the command line

The obvious alternative is ExifTool itself, which is what ExifCleaner calls underneath. The difference is not capability, since ExifTool's writer support is the ceiling both share. It is the interface and the intake contract.

ExifTool exposes its full reader and writer catalog. ExifCleaner deliberately accepts only a tested allowlist: common image formats, a short media list, and PDF. That narrower surface is why the app can refuse RAF and MKV at intake instead of writing something it cannot vouch for. A command-line ExifTool user gets no such guardrail and can write tags into formats the tool only half-supports, which is exactly how partial removals happen. In exchange, the command line handles anything outside the allowlist, runs headless on a server, and scripts into a build pipeline. ExifCleaner is a desktop GUI with no documented headless mode, so it does not belong in CI.

If you want the underlying engine without the app, install ExifTool directly. If you want a file list, a diff view and folder recursion without writing a shell loop, ExifCleaner is the wrapper. Note that the app ships its own ExifTool, updated through update_exiftool.pl in the repository root, so the version you get is the one the release pinned, not whatever is on your PATH.

Licence, maintenance and what an upgrade costs you

The project is MIT licensed, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are kept. That is permissive enough for internal corporate deployment. The README does not discuss trademark or redistribution of the ExifCleaner name and artwork, and nothing here should be read as legal advice.

The maintenance picture is unusual. v4.0 was the first release since v3.6.0 in May 2021, described as a complete modernization. Since then the cadence has been rapid: v4.1.0 and v4.2.0 both landed on 2026-08-03, and v4.2.1 on 2026-08-22. The repository is not archived, and the last push was on 2026-08-22. That is a recent burst after a long gap, which is worth weighing against the assumption of steady maintenance.

Upgrade cost is low but manual. There are no automatic updates, so a new version means downloading the artifact and repeating the first-launch bypass on macOS, since the app stays unsigned. Nothing migrates because the app stores no state worth migrating. The heavier cost is the ExifTool dependency: because the app bundles a pinned ExifTool, a fix for a format like TIFF or AVIF arrives only when the maintainer runs update_exiftool.pl and cuts a release. You cannot bump the engine yourself without building from source.

Editorial conclusion

Adopt ExifCleaner if you handle photo or video batches on a desktop and want a drag-and-drop interface rather than ExifTool command lines. Skip it for PDF redaction and for any workflow that needs a signed, notarized binary on managed endpoints. Before trusting it, verify the SHASUMS256.txt checksum and test one TIFF and one AVIF file, since the README lists partial removal on both as open investigations.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes