Remove Metadata From Photos Before Posting on Mastodon

Mastodon is not one app. Media federates. Wipe GPS, device, and timestamp tags before a JPEG is copied to servers you did not pick.

Ready to clean a photo? MetadataWipe processes JPEG and PNG files locally in your browser — no account, and your file never leaves your device.

Open MetadataWipe tool

Mastodon (and much of the fediverse) distributes posts by copying them between instances. A photo attached to a toot can be fetched and stored by servers that follow you, boost you, or crawl a public timeline. That architecture is a feature. It is also a reason not to treat 'the instance admin is a friend' as the entire threat model. EXIF GPS, camera serial-adjacent tags, and DateTimeOriginal ride in the file until something strips them. You should not assume every receiving server or client will.

MetadataWipe is the local habit before you attach media in the official web UI, Ivory, Tusky, or any other client: clean JPEG/PNG on your device, then attach the cleaned file. This sits next to the Bluesky and Twitter (X) guides on this site. Those networks have their own redistribution stories. Mastodon's is federation: more copies, more caches, less reason to leave a home pin in the header 'because I trust my mods.' A public toot on a large instance can be fetched by servers you will never visit. A followers-only toot can still be saved by someone you allowed in. In both cases the JPEG bytes are the thing you still control.

What to strip before a Mastodon image post — and why

Alt text is public on purpose. EXIF is not alt text. Do not store the precise pin in the file because you already wrote a city in the description.

How to use MetadataWipe

  1. 1. Export the JPEG or PNG you will attach. If the phone saved HEIC, convert to JPEG first.
  2. 2. Open MetadataWipe and load the file locally. Review GPS and camera fields.
  3. 3. Remove all common metadata blocks and download the cleaned copy.
  4. 4. Attach the cleaned file in your Mastodon client. Do not pick the original from the recents grid by habit.
  5. 5. If you cross-post the same image to another network, attach the same wiped file there too.

Realistic scenarios

Scenario A — Pseudonymous poster: A person uses a nickname instance. They wipe device tags so a named photography account on another site is harder to correlate.

Scenario B — Local politics: A rally photo is public. They strip GPS so the file does not add a home or workplace pin from earlier in the day.

Scenario C — Artist shop: Product photos go on a maker account. They wipe GPS so the studio address is not in every JPEG.

Scenario D — Cross-poster: The same cleaned file is attached to Mastodon and Bluesky so neither hop receives a geotagged original.

Federation, clients, and other social guides

Boosts and remote copies mean you cannot audit every cache. The control you have is the bytes you first attach.

Some instances may transcode media. Transcoding is not a privacy contract. Wipe first.

For neighboring networks see photos before Bluesky and photos before Twitter/X. The wipe is the same; the distribution story is what changes.

Hashtags and public timelines increase how many clients fetch media. That is not a reason to avoid Mastodon; it is a reason to treat every image attach as a file that will be copied. Wipe once, then compose.

If you post from a phone, the recents grid will keep offering the geotagged original. Attach from a wiped-exports album or the downloaded -metadatawipe file so a fast thumb press does not undo the work.

Common mistakes

Trusting instance policy instead of the file. Admins change. Servers die. Remote copies remain. Clean the JPEG.

Wiping for Mastodon but attaching the geotagged original to a cross-post. One original poisons both networks. Wipe once, attach many times.

Posting a screenshot of a photo instead of wiping. Screenshots add new device tags and may still be a photo of a geotagged original sitting in the frame's pixels only — but the screenshot file has its own header. Wipe the screenshot too if that is what you post.

Editing after wipe in an app that re-saves EXIF. Final export, then wipe, then attach.

A toot is copied, not merely displayed

Mastodon and the wider fediverse fetch and store media on instances you did not pick. A JPEG attached to a public post can land on servers that follow you, boost you, or crawl a timeline. Admins you like are not the whole threat model. EXIF GPS, device strings, and DateTimeOriginal ride in the file until something strips them. You should not assume every receiving server, proxy, or client will.

MetadataWipe is the local habit before Ivory, Tusky, the web UI, or any other client: clean JPEG/PNG on the device, then attach the cleaned file. No server upload to MetadataWipe. The tool will not strip a Mastodon video attachment; export a still if you need a custom thumbnail, then wipe that still. Convert HEIC to JPEG first.

Cleaning JPEG/PNG before any client attach

Export the still. Open it in the tool on this page.

  1. Strip GPS, camera, and timestamp fields so federation copies a header-light file.
  2. Download the export and attach that path in your client. Do not re-pick Recents.
  3. If you cross-post the same image to another network, attach the same wiped file there too.
  4. Wipe alt-text is not metadata wipe — write good alt text, and still strip EXIF. They are different kindnesses.

Deletes on your home instance do not un-copy media already fetched elsewhere. Start clean.

Boosts and mirrors that outlive your delete

A pseudonymous poster uses a nickname instance. They still shoot on a named photography phone. Device tags can correlate the nickname with a public portfolio elsewhere. Wiping stills before toots makes that correlation harder. Backgrounds in the pixels can still match; headers should not help.

A local-politics account posts a rally photo. The rally is public. The file also has GPS from earlier in the day at a workplace. Boosts copy that JPEG widely. Wiping before attach drops the workplace pin the caption never mentioned.

An artist shop posts product stills. Federation means random instances cache the JPEG. Home-studio GPS in EXIF is a gift to anyone who saves the original. Wipe, then attach.

Mastodon mistakes that treat instance policy as EXIF deletion

Some instances transcode. Some store originals. Policy pages change. Your export should not depend on them.

  1. Trusting “we strip EXIF on attach” without verifying a boosted copy saved from another instance. Wipe first.
  2. Attaching from a Nextcloud or S3 link that still points at the tagged master. Point at the cleaned object.
  3. Using a scheduled bot that reads a camera folder. Point the bot at a folder of wiped exports.
  4. Posting a video and a custom poster, wiping neither still. Wipe the poster here; handle the video in an editor.

Related guides

See also:

Frequently asked questions

Does Mastodon strip EXIF on attach?

Behavior varies by server software version, client, and transcoding. Do not depend on it. Wipe locally.

Is this different from Bluesky advice?

The wipe is the same. Mastodon's extra issue is federation: more servers may store the media. Assume copies.

Unlisted or followers-only toots — still wipe?

Yes. Followers save files. Screenshots happen. Headers travel with the bytes.

Does MetadataWipe federate or send the image?

No. It never leaves your device during cleaning.

Strip EXIF, GPS, camera details, and common photo metadata in your browser.

Try MetadataWipe free