TL;DR: Yes, for location data specifically — Bluesky's backend, the Personal Data Server (PDS), scans every uploaded image blob at upload time and strips location EXIF by default, a behavior documented directly in the AT Protocol engineering team's own GitHub issue tracker. This is a server-side, mandatory pass, not a client toggle you have to remember to hit. But "strips location EXIF" is a narrower claim than "strips all metadata." The scan targets the GPS IFD, not the full EXIF block — camera make and model, timestamps, software tags, and embedded thumbnails aren't confirmed to be part of the same pass, and Bluesky hasn't published a field-by-field list the way some platforms have. There's also an open, unresolved feature request from photographers asking Bluesky to preserve licensing, copyright, and alt-text metadata instead of stripping everything indiscriminately — which tells you the current default is closer to "wipe it" than "curate it." And Bluesky's direct messages, which are unencrypted and reviewable for Trust & Safety, don't have documented parity with the public-post scanning behavior.
Does Bluesky remove photo metadata?
The short answer is that Bluesky removes location metadata from photos as a matter of engineered policy, not accident. This is unusually well-documented for a social platform, because Bluesky's core infrastructure — the AT Protocol — is open source, and the decision to strip location EXIF was made and recorded in public. In AT Protocol issue #522, the engineering team wrote plainly: "we decided that by default image blobs should be scanned by the PDS to ensure they don't have any location EXIF metadata, with this behavior override-able via a flag." That single sentence tells you three things worth unpacking: the scan happens on the PDS (the server that hosts your account's data, whether that's Bluesky's own infrastructure or a self-hosted instance), it happens at upload time rather than at display time, and it is the default — meaning a developer building on the protocol would have to deliberately flip a flag to skip it, not the other way around.
That's a meaningfully different architecture from platforms that strip metadata only when generating a resized preview for their app, while quietly keeping the original untouched on a CDN somewhere. Bluesky's stated intent is to sanitize the blob itself before it's stored, not just the copy that gets served back to your followers' feeds. If you want the deeper mechanics of what a JPEG's EXIF block actually contains before any platform touches it, our explainer on what EXIF data is breaks down the APP1 segment, the GPS IFD, and why location tags in particular are the highest-stakes field.
What Bluesky's engineers actually committed to, in their own words
It's worth being precise about scope here, because "Bluesky removes metadata" and "Bluesky removes location metadata" are not interchangeable claims, and the primary source only supports the narrower one. The GitHub issue is titled, verbatim, "Verify that uploaded image blobs have no location EXIF metadata" — the word "location" is doing real work in that title. The engineering discussion around it was specifically about the GPS IFD, the nested EXIF structure that holds latitude, longitude, altitude, and GPS timestamp. There's no equivalent public commitment covering Make, Model, Software, DateTimeOriginal, or the embedded thumbnail that many cameras and phones tuck into a JPEG alongside the full-size image.
That gap matters less for casual users — most people don't lose sleep over their phone model leaking — but it matters more than most people assume for anyone whose photos might be traced back to a device, a shoot date, or an editing workflow. A journalist posting a photo without realizing the file still carries DateTimeOriginal and camera serial-adjacent tags has a different risk profile than one whose main concern is GPS coordinates. Bluesky's public documentation, to date, speaks to the GPS case and doesn't make a broader claim, so treating the rest as "probably also stripped, since they said metadata is gone" is an assumption the primary source doesn't actually back.
Where the scan happens, and why that's stronger than a client-side strip
The PDS-level implementation detail is the part worth sitting with, because it changes the failure modes compared to an app that strips EXIF only in its own official client. If the scan runs on the server at blob-upload time, then it should apply regardless of which client posted the image — the official Bluesky app, a third-party AT Protocol client, or a bot posting through the API — as long as that client is talking to a standard PDS that hasn't had the override flag flipped. That's a real advantage over, say, a platform where metadata stripping happens only inside one specific mobile app's upload pipeline, leaving third-party clients or direct API uploads to bypass it entirely.
The tradeoff is that the scan's scope was engineered around a specific privacy threat model — accidental GPS leaks — and privacy engineering that solves one clearly-defined problem well doesn't automatically solve adjacent ones. The team's own framing, that the "ignore EXIF" behavior needed a flag "in only one place," suggests the design optimized for enforceability over comprehensiveness. A narrow, reliably-enforced rule beats a broad, unevenly-enforced one, but it's still narrow.
The unresolved fight over preserving metadata, not just stripping it
A second GitHub issue complicates the picture in an interesting way: issue #6773 is an open request asking Bluesky to preserve certain metadata — specifically licensing information, copyright notices, and alt text — rather than wiping everything on upload. This is coming from photographers and artists who post original work to Bluesky and want attribution and licensing terms to travel with the file, the same way IPTC copyright fields are meant to function. The fact that this issue exists, and remains open rather than resolved, tells you the current default behavior is blunt: it removes location data as documented, and in practice strips or fails to preserve other metadata fields that some users would actually prefer to keep.
The proposal under discussion frames any future metadata-preservation feature as something that should be "completely opt-in" and should "show exact data about to be shared" before a user posts — which is the right instinct, but also confirms that as of this writing, no such curated-preservation feature ships by default. If you're a working photographer using Bluesky to share portfolio work, don't assume your copyright or licensing metadata makes it through; assume it doesn't unless you've separately verified it on a post you've published, the same way our guide on what platforms actually do before you sell photos recommends for any marketplace or social upload.
Do Bluesky's direct messages get the same treatment?
This is the honest gap in the public record. Bluesky's privacy policy states that direct messages are stored and processed, are unencrypted, and "can be accessed for Trust & Safety purposes" — a materially different privacy posture than the public timeline, where the content is intentionally public anyway. What the policy and the engineering issue tracker don't spell out is whether an image attached to a DM travels through the identical PDS blob-upload path that triggers the location-EXIF scan, or whether DMs use a separate storage mechanism that might not inherit the same default.
Architecturally, it's plausible that DM attachments hit the same underlying blob storage as post images, since AT Protocol was built around a unified data model. But "plausible, given the architecture" is not the same as "confirmed by a policy statement or an engineering post," and we'd rather tell you that distinction exists than imply a guarantee Bluesky hasn't made. If you're sending a photo in a Bluesky DM that you'd rather not have traceable — a location-tagged image, a photo with a serial number visible in metadata, anything sensitive — treat that upload with the same caution you'd apply to an email attachment, not the confidence of a documented public-post scrub.
What this means if you post from Bluesky regularly
For most day-to-day posting — vacation photos, event pictures, screenshots — the PDS's default location-EXIF scan is doing real, meaningful work, and it's a stronger guarantee than what most competing platforms disclose, precisely because it's written down in the engineering record rather than inferred from a support article. That's genuinely worth something. But it's a scan for one category of risk, not a metadata-privacy guarantee across the board, and the open feature request to preserve rather than strip other fields tells you the current default treats "not location" metadata inconsistently — sometimes surviving, sometimes not, without a documented field list either way.
If you're a photographer who wants licensing and copyright metadata to travel with your posts, don't count on Bluesky to keep it — file your own copy with that metadata intact elsewhere, since Bluesky's platform behavior currently trends toward removing it rather than preserving it. If you're posting something sensitive in a DM, don't lean on the public-post policy language to cover you. And if precision matters — you need to know, not assume, exactly what's in a file before it leaves your device — the only reliable move is to control the file yourself before any platform's scanner ever sees it.
Metadata Cleaner strips EXIF, GPS, XMP, and IPTC data from photos and video entirely in your browser before you upload anywhere, so you're not depending on any platform's scan catching everything it's supposed to. Try Metadata Cleaner free and check the file yourself before it goes out.
For more on how other platforms handle this, see our breakdowns of Twitter/X, Threads, and Instagram.