TL;DR: Mostly yes — for the person on the other end. When you send a photo through Facebook Messenger's normal photo picker, the image is recompressed and its EXIF block is stripped before delivery: the recipient's copy arrives without GPS coordinates, camera Make and Model, DateTimeOriginal or embedded XMP/IPTC records. But the file you upload is your original, and Meta's own data policy says it collects metadata from the content you provide — including photo location and creation date — during ingestion. So the honest answer is: Messenger removes metadata from the recipient's copy while Meta reads it on the way through. End-to-end encrypted chats change what Meta's servers can see, not what your file contains when it leaves your phone. Desktop file attachments and shared cloud links can bypass the photo pipeline entirely. The only version of the story you control is the file itself: strip it before Messenger ever touches it.
Does Facebook Messenger remove photo metadata?
For the recipient, yes. Messenger runs images sent through its photo picker down the same ingestion pipeline Facebook has used for years: the photo is resized, recompressed and re-encoded, and the EXIF application segment — GPS IFD included — does not survive the trip. If a friend downloads a photo you sent in a Messenger thread and opens it in an EXIF viewer, they will find the JPEG dimensions, the compression signature of Meta's encoder, and very little else. No coordinates, no camera body, no lens, no capture timestamp.
That matches what we have seen across Meta's products. Photos posted to Facebook and Instagram come back out stripped, and Messenger inherits the same server-side processing. It is one of the reasons people who reconstruct their old conversations from a Facebook data archive discover the pain of missing capture dates: the media files in the archive carry no DateTimeOriginal, because it was never kept with the file.
So if the question is "can the person I'm chatting with pull my home address out of a photo's GPS tag?", the answer for a normal Messenger photo send is no.
But that is only half the question — and the less interesting half.
Stripped for them, read by Meta first
The upload that leaves your phone is your original file, metadata and all. The stripping happens inside Meta's infrastructure, which means the metadata exists on Meta's servers at the moment of ingestion — and Meta's privacy policy is explicit that the company collects information from the content you create, "such as metadata," naming the location of a photo and the date a file was created as examples.
Photo by MART PRODUCTION on Pexels
Think about what that means in practice. Every photo you have ever sent through Messenger's photo picker arrived at Meta carrying whatever your camera wrote into it: GPS coordinates accurate to a few meters, the exact second of capture, the device that took it. The recipient never sees any of that. Meta's pipeline does — and metadata is precisely the kind of structured, machine-readable signal that advertising systems are built to consume. Location history you never typed anywhere, inferred one shared photo at a time.
This is the pattern worth internalizing about platform metadata stripping in general: stripping protects you from the recipient, not from the platform. The platform is the one party guaranteed to see the file before the stripping happens.
What about end-to-end encrypted chats?
Messenger conversations are end-to-end encrypted by default — Meta completed that rollout starting in December 2023 — and E2E genuinely changes the picture, though not in the way people usually assume.
With end-to-end encryption, media is encrypted on your device before transmission, so Meta's servers relay ciphertext they cannot open. That is a real privacy gain: in an E2E thread, Meta's ability to read your photo's EXIF server-side is dramatically reduced. But three caveats keep us from calling it a full solution.
First, the Messenger client itself still processes the photo on your device before encrypting — recompressing and resizing it — and client-side code can read anything in the file. Meta's own app is the thing doing the encrypting. Second, E2E protects content, not message metadata: who you messaged, when, from what device and IP — all of that Meta still collects, encryption or no. Third, encryption in transit says nothing about the recipient's copy once decrypted, or about what happens if either side reports, forwards or re-uploads the image through a non-E2E surface.
E2E is worth having. It is not the same thing as the file being clean.
How Messenger compares with WhatsApp, iMessage and the rest
Within Meta's own family, behavior is consistent: WhatsApp strips EXIF from photos sent as photos, and so does Messenger. Both also share the same caveat — send the image as a document/file and it can travel untouched, original bytes and all.
Outside Meta, the field is a patchwork. iMessage preserves metadata end to end — Apple delivers the file you sent, GPS included. Telegram strips EXIF on compressed photo sends but delivers originals when you send as a file. Signal strips metadata and encrypts end to end, the strongest default of the group. The result is that no habit learned on one app transfers safely to another: the same tap-and-send gesture leaks your location on iMessage, hides it from the recipient on Messenger, and hides it from nearly everyone on Signal.
That inconsistency is the strongest argument for not letting the platform make the decision at all.
The edge cases that bypass the stripping
Three sending paths deserve particular caution, because they route around the photo pipeline that does the scrubbing.
Photo by RDNE Stock project on Pexels
File attachments from desktop. Messenger on the web and desktop lets you attach arbitrary files. A JPEG sent through the file-attachment flow rather than the photo picker is treated as a document — and documents are delivered as-is. The recipient gets your original, EXIF block intact. The visual difference in the chat is subtle; the metadata difference is total.
Links instead of uploads. Paste a Google Drive, Dropbox or OneDrive link into a chat and Messenger transfers nothing at all — recipients open the file stored in your cloud account, which is the original you put there. No Meta pipeline, no stripping, and the cloud copy keeps exposing metadata to everyone with the link for as long as it exists.
Forwards and re-shares. A photo that entered the ecosystem clean stays clean when forwarded. But a photo that entered through a preserving path — an iMessage save, an email attachment, a file-mode send — carries its metadata into every subsequent hop that doesn't recompress it. You rarely know a photo's routing history when you pass it along.
How to check what your photos are carrying
Before deciding how much any of this matters to you, it helps to see the problem with your own eyes. Take a photo you recently sent through Messenger — the original in your camera roll, not the delivered copy — and open its details. On an iPhone, swipe up on the photo or tap the info button; on Android, open the photo in Google Photos and tap the three-dot menu. If a map appears under the image, that photo carries GPS coordinates, and every platform you have ever uploaded it to received them.
Then do the reverse test: have a friend send the same photo back to you through Messenger and inspect the downloaded copy. The location will be gone. The gap between those two files — what you hold versus what arrives — is exactly the metadata Meta's pipeline consumed in the middle.
The dependable fix: strip before you share
Every uncertainty above — which send path scrubs, what Meta reads at ingestion, whether the thread is E2E, what the recipient does next — evaporates if the file carries nothing in the first place.
Run the photo or video through Metadata Cleaner before you attach it. The tool rewrites images, video and audio files without their EXIF blocks, GPS IFDs, XMP and IPTC packets, PNG text chunks, embedded thumbnails and container atoms — and it does the work entirely in your browser, so the file never leaves your machine on the way to being cleaned. Then send the clean copy through Messenger, attach the clean copy as a file, store the clean copy in the cloud folder you link from.
Once the file itself is clean, Messenger's behavior stops mattering. Meta cannot harvest coordinates that are not there; a file-mode send cannot leak a GPS tag that was removed before upload; a forward cannot resurrect a capture timestamp that no longer exists. And the habit transfers everywhere — the same clean file is safe in iMessage, safe in Telegram, safe in an email, without you needing to remember which platform scrubs which field on which upload path this year.
Conclusion
Facebook Messenger does remove photo metadata from the copy your recipient receives — its ingestion pipeline recompresses images and discards EXIF, GPS and embedded records along the way. But the stripping happens on Meta's side of the wire, after your original has already arrived, and Meta's privacy policy reserves exactly that metadata for its own collection. End-to-end encryption narrows what Meta's servers can see; it does not clean the file. Desktop file attachments and cloud links skip the scrubbing entirely. Treat Messenger's stripping as a courtesy to your recipient, not a protection for you — and hand every platform a file that has nothing left to tell.