ExifCleaner cleans 30 formats, refuses RAF and cannot erase PDF metadata

PDF is on the intake list and off the guarantee list

The extension list puts .pdf under Documents, and the format table then takes PDF away again. That row states that ExifTool writes a reversible PDF update, so the original metadata remains recoverable and ExifCleaner cannot securely erase PDF metadata. It is filed as a documented limitation with issue #216, which is a different category from a bug: no retry changes the outcome, because the writer underneath is reversible by design.

So the user-facing path stays silent where it matters. A PDF goes in, a processed PDF comes out, and nothing at intake says the metadata was hidden rather than destroyed. The paragraph that would have spelled out the PDF behaviour ends mid-link, at exiftoo, so the rest of that citation and any wording after it are not in the file.

Two formats are refused, two are accepted with a weaker promise

The same table covers four more formats, and the refusals are not the same kind. RAF is accepted at intake, since .raf sits in the image extension list, but the operation is refused before writing and the source is left unchanged, because a safe cleaned RAF artifact cannot currently be guaranteed. MKV is turned away earlier: ExifTool exposes Matroska metadata for reading but provides no writable tags, so ExifCleaner rejects MKV at intake under issue #182, which lines up with .mkv being absent from the media list.

TIFF and AVIF are the partial cases rather than refusals. TIFF removal may be partial because some metadata can remain in IFD0, tracked as an open investigation in #199, and AVIF has a user-reported partial removal case open in #215. Between them: one format accepted then refused at write time, one refused before it starts, two accepted with a weaker promise, and PDF accepted and documented as not erasable.

Unsigned on every platform, and macOS 15 moved the steps

The app ships without a code signature, and the file explains why in money and in names. Signing macOS builds requires an Apple Developer certificate at $99/year, and the certificate embeds the holder's legal name, which macOS then displays in the Gatekeeper dialog. Windows wants a separate EV certificate at $200 to $600/year tied to a verified legal identity. For a privacy tool maintained anonymously the project says that tradeoff is not one it is willing to make, and the package metadata agrees in spirit: the author field carries a GitHub noreply address.

The workarounds differ per platform, and one of them changed. On macOS 14 and earlier you right-click the app, choose Open, then Open again in the dialog. On macOS 15 and later right-click no longer works at all: double-click once, let it be blocked, then open System Settings, Privacy & Security and click Open Anyway next to the ExifCleaner message. Windows shows Windows protected your PC, where More info leads to Run anyway. Linux has no gatekeeping, and the AppImage only needs to be made executable.

Published checksums and a CI install stand in for a signature

What the project offers instead is verification you can run. Every release includes a SHASUMS256.txt file, and the check is one line:

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

That confirms the download is byte for byte what CI built. The stronger claim is about the build itself: every release is built in public by the GitHub Actions release workflow from tagged source anyone can read, and CI installs and runs the actual artifact before it can be released, mounting the DMG, installing it, launching it and stripping metadata from a test image, so a build that does not work never reaches the release page.

The file also draws a line around distribution: only downloads from the GitHub releases page are theirs, and builds shared through other channels are not verified. Nothing published is a web build. The artifacts are a dmg, a portable exe or a setup exe on Windows, and AppImage, deb and rpm files on Linux, with an Arch package named exifcleaner-bin for paru -S exifcleaner-bin.

Four years of silence, then three tags in eleven days

The release rhythm changed shape twice. v4.0 was the first release since v3.6.0 in May 2021, and the file calls it a complete modernization: five privacy switches (preserve orientation, save as copy, macOS extended attribute removal, preserve timestamps and folder recursion), a before and after metadata diff, language switching across 25 locales without a restart, a hardening pass covering CSP, Electron Fuses, IPC validation, navigation hardening and permission gates, separate native Apple Silicon and Intel builds so no Rosetta is needed, and a test count of 265 unit tests plus 42 end to end.

After that the tags came quickly: v4.3.0 on 2026-09-18, v4.4.0 on 2026-09-24, v4.5.0 on 2026-09-29, with the package version field reading 4.5.0 to match. Publishing is fenced off from a workstation: the release script in package.json echoes a message pointing at the workflow_dispatch workflow and exits 1, so a version bump cannot be cut locally. CHANGELOG.md and RELEASE_NOTES.md sit at the root for the history.

The primary language is Perl, the app is Electron

The repository's detected primary language is Perl, and that is not where the application lives. The desktop client is an Electron project: package.json is named exifcleaner with the product name ExifCleaner, its type is module, main points at ./out/main/index.js, and the tree carries electron.vite.config.ts, tsconfig.json beside tsconfig.renderer.json for the main and renderer split, playwright.config.ts, vitest.config.ts, yarn.lock, .prettierrc and .npmrc.

The Perl comes from one root script, update_exiftool.pl, which the update-exiftool npm script invokes as ./update_exiftool.pl, together with whatever lives in the scripts directory. Two details in that package file are worth a second look. Three scripts, start, dev and preview, clear ELECTRON_RUN_AS_NODE before calling electron-vite, and the file gives no reason for it. And the repository root also carries CLAUDE.md, a .claude directory and a prompts directory, so part of the working setup is aimed at an assistant.

Thirty extensions, five switches, and no network traffic

Intake is deliberately narrow. The list is 22 image formats: .jpg, .jpeg, .png, .gif, .tiff, .tif, .webp, .heic, .heif, .bmp, .avif, .svg and the raw extensions .cr2, .cr3, .nef, .arw, .orf, .rw2, .raf, .dng, .pef and .srw. Then seven media formats, .mp4, .mov, .avi, .m4a, .m4v, .3gp and .wmv, and one document type. The file calls that the app's tested intake contract rather than ExifTool's much broader reader and writer catalog.

Batch speed comes from ExifTool's stay-open protocol instead of one process per file. The five privacy switches each change what survives: four of them decide what the app leaves in place, including orientation data, a copy of the original and file timestamps, and one asks it to delete macOS extended attributes. Folder recursion extends processing to everything inside a dropped folder, expanding a processed file shows a before and after diff, dark mode follows the OS preference, and the app has no automatic update path and makes no network traffic at all.

Editorial conclusion

ExifCleaner is a sensible choice if you need a point and click way to strip location data from photos before posting them, on macOS, Windows or Linux, 64-bit, on a recent enough system. It is the wrong tool if your requirement is provable erasure: the project states that PDF metadata stays recoverable, that TIFF removal can be partial, and that an AVIF case is still open. Two practical notes before you start. The app is unsigned, so budget one launch for the Gatekeeper or SmartScreen step, and on macOS 15 the right-click route no longer works. And take the artifacts from the releases page only, checking SHASUMS256.txt if you want certainty, because builds shared through other channels are not the project's.

Frequently asked questions

Official sources

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