TL;DR: Mostly yes, for the ordinary path. Mastodon's server software unconditionally re-encodes images you upload to your home instance, and that re-encode strips the standard EXIF block — GPS coordinates, camera make and model, capture timestamp — as a side effect, not a documented privacy feature. But federation changes the risk model in a way centralized platforms don't have: once your instance strips a photo, other servers that receive it through ActivityPub do not re-process it — they trust that the origin already handled it. That's fine when your instance is a standard Mastodon build, but it means the guarantee only holds if every hop in the chain actually stripped the file, which isn't true for every fediverse server implementation or every media type. Video is the weaker case — a documented Mastodon bug showed GPS coordinates surviving in re-encoded MP4 files. The only version you fully control is the one you strip yourself before it reaches any instance.
Does Mastodon remove photo metadata?
For the common case — you open the compose box, attach a photo, and post it — Mastodon does remove the standard EXIF block from that image before anyone sees it. This isn't a policy decision announced in a privacy page; it's the outcome of a 2018 code change to Mastodon's media pipeline. Pull request #8714, titled "Unconditionally re-encode locally-uploaded images to strip metadata," rewrote every local image upload through ImageMagick regardless of whether the file needed resizing. The re-encode discards the APP1 segment that starts with Exif\0\0, and with it the GPS IFD, the DateTimeOriginal tag, and the camera's make and model string.
Before that patch, Mastodon had a quieter problem: a "lazy thumbnail" optimization skipped re-processing images that were already the right dimensions, which meant a photo straight off a phone could pass through untouched if it happened to match the expected size. The fix closed that gap by making the strip unconditional for anything a user uploads directly. That history matters because it shows the stripping behavior wasn't part of Mastodon's original design — it was patched in after someone noticed the hole, which is the same pattern we've seen on Reddit and other platforms whose metadata handling turned out to be a byproduct of image processing rather than a deliberate privacy control.
What happens to the file on your home instance?
When you attach a photo in the compose box, it uploads to your home instance — the specific server you registered on, whether that's mastodon.social, a small single-user instance, or something run by your workplace or community. That server's MediaAttachment processor runs the image through re-encoding immediately, before the post is ever federated anywhere. The output file is what gets stored, thumbnailed, and eventually pushed out to every other instance that needs to display it.
This is the part of the pipeline you can actually verify: download a photo you just posted from your own profile and check its EXIF with any reader. For a standard JPEG or PNG posted the normal way, the GPS and camera fields should be gone. If you're unfamiliar with what those fields actually contain, our explainer on what EXIF data is walks through the full tag set a camera writes into every frame — location, device, timestamp, and more.
Photo by Abdulkadir Emiroğlu on Pexels.
Does federation re-strip metadata, or does it trust the origin?
This is where Mastodon diverges from every centralized platform we've covered. Instagram, TikTok, and Reddit each control one pipeline: upload, re-encode, serve. Mastodon is federated — your post doesn't just live on your instance, it gets pushed via ActivityPub to every server that follows you or that a follower's server needs to fetch it from. That raises an obvious question: does each receiving instance re-process the media, or does it just display what it was handed?
The answer, according to Mastodon's own maintainers, is the latter. In the discussion on PR #8714, project lead Eugen Rochko (Gargron) explained the reasoning directly: "We don't really care about EXIF metadata in remote images because presumably they already stripped it themselves when the image was turned into the dimensions we expect." In other words, Mastodon's re-encode is deliberately applied only to locally uploaded media — files remote instances receive through federation are trusted, not re-scrubbed. This is a sensible design for reducing redundant server load across a network with thousands of independent instances, but it means the privacy guarantee is only as strong as the weakest instance in the chain. If your home server strips correctly, you're covered. What happens on someone else's server, running someone else's configuration, is outside your control the moment your post federates there — the same structural point we made about Discord's inconsistent per-surface stripping, just at the scale of an entire network instead of one app's upload paths.
What about Pleroma, Akkoma, and other fediverse servers?
Mastodon is one implementation among several that speak ActivityPub. Pleroma, its fork Akkoma, and GoToSocial are common alternatives, and they don't share Mastodon's Ruby codebase or its unconditional-re-encode behavior. Pleroma and Akkoma strip metadata through configurable upload filters rather than a hardcoded step — Pleroma.Upload.Filter.Mogrify with a strip action, or the more targeted Pleroma.Upload.Filters.Exiftool.StripLocation, which removes GPS and location fields specifically while leaving color profile data intact. Both are opt-in filters that a server administrator has to enable in the instance's configuration; they aren't guaranteed defaults the way Mastodon's re-encode is.
That distinction matters in practice. If you follow someone on a Pleroma or Akkoma instance, or your own account lives on one, whether your uploaded photos get stripped depends on how that specific instance's admin configured the upload pipeline — not on a network-wide standard. A small self-hosted instance run by someone who never enabled the StripLocation filter will federate images with their original EXIF intact, and because of the trust model described above, no downstream Mastodon instance will catch or fix that on the way through.
Does Mastodon strip metadata from video?
Video runs through a separate pipeline, and it's the weaker link. Mastodon transcodes uploaded video with ffmpeg, which generally rebuilds the container and should drop most metadata as a side effect — similar to what happens on Google Photos exports and other transcoded uploads. But "should" isn't "always." A documented Mastodon issue, #22948, recorded a specific failure case: a video recorded on a phone, synced to Google Photos, downloaded as an MP4, and then uploaded to Mastodon retained its GPS coordinates in the ©xyz atom after the platform's own transcode. Running mediainfo on the file pulled down from the Mastodon instance still returned real latitude and longitude, not a stripped or sentinel value.
That single reported case illustrates the broader pattern worth remembering: MP4 and MOV containers store location, device, and timestamp data inside moov/udta atoms that a straightforward transcode doesn't always fully rebuild, especially depending on which fields the source file used and which ffmpeg settings the instance runs. A video often carries more revealing metadata than a photo, because it can record location across a longer span of filming rather than a single frozen moment.
Photo by panumas nikhomkhai on Pexels.
What's the debate over stripping C2PA and authorship metadata?
Mastodon's blanket re-encode has a cost that cuts the other way: it destroys metadata some creators actually want to keep. GitHub issue #2710 raised this early on — photographers who embed copyright and authorship information in their EXIF/IPTC fields lose that attribution the moment the file passes through Mastodon's upload pipeline, with no way to opt out. More recently, issue #35100 reopened the question specifically around C2PA — the Coalition for Content Provenance and Authenticity manifest format that cryptographically signs an image's edit history to prove it hasn't been manipulated by AI. Because C2PA data lives inside the same EXIF container that carries GPS coordinates, Mastodon's strip-everything approach removes verifiable provenance credentials along with the location data, even though the two serve opposite purposes — one protects the poster's privacy, the other protects the viewer's trust in what they're looking at. We cover that standard in more depth in our piece on C2PA content credentials. As of this writing, Mastodon hasn't shipped a way to distinguish the two, so the re-encode remains all-or-nothing.
What does upload-time stripping still not protect?
Even in the clean case — a JPEG uploaded normally, GPS gone from the re-encoded copy on your home instance — two limits are worth naming. First, EXIF removal is not image anonymization. The pixels themselves can still show a street sign, a license plate, or a reflection that identifies where a photo was taken, regardless of what metadata survives. Second, location can leak through channels the EXIF strip never touches: a caption that names a venue, an optional geolocation tag some ActivityPub clients attach to the post itself rather than the image file, or a reply thread that fills in the details a stripped photo left out. Mastodon's own interface doesn't currently expose post-level geolocation even though the protocol supports it, but that's a reason for caution, not reassurance — a client that does surface or attach it bypasses the image-processing pipeline entirely.
How do you remove photo metadata before posting to Mastodon?
The dependable fix is the one that doesn't depend on any instance's configuration: strip the file yourself before it reaches your home server at all. Metadata Cleaner does this in your browser — drop in a photo or video, and it rewrites the file without its EXIF block, GPS IFD, XMP and IPTC records, PNG text chunks, and embedded thumbnail, then hands back a clean copy. Because it handles video the same way it handles images, it closes the ffmpeg gap that let GPS data survive in the documented Mastodon bug above. Nothing uploads to us; the processing happens locally on your device.
Once the file is clean before it ever touches Mastodon, every downstream question stops mattering — whether your instance's re-encode is thorough, whether a follower's Pleroma server enabled its strip filter, whether the transcode fully rebuilds the video container. There's nothing left in the file for any of those steps to catch or miss. For the full walkthrough across desktop and mobile, see how to strip EXIF data from a photo, and if you want the deeper mechanics of what a "strip" operation actually touches field by field, our explainer on metadata scrubbing covers it.
Mastodon removes most photo metadata, on the ordinary upload path, on a standard instance — three qualifiers that all matter more in a federated network than on a single centralized platform. Strip the file yourself and none of them are load-bearing anymore. Try Metadata Cleaner free and post the clean copy.