Some strip it, some keep it, and 'document' mode changes the answer

Most messaging apps strip a photo's metadata, but not because anyone building them set out to protect your privacy. They do it as a side effect of recompressing every image sent through the normal photo-sharing flow, and that side effect disappears the moment you send the same photo as a file instead.

Why recompression strips metadata as a byproduct

Chat apps are built to move images quickly over unreliable connections, so the default photo-sharing path usually resizes and recompresses whatever you send, producing a new file rather than transmitting the original bytes. Building a new file from decoded pixels is, structurally, the same act as taking a screenshot: the process starts fresh and has no camera EXIF to carry over, because nothing in a recompression pipeline reads the old metadata block and writes it back out on the other end. This is convenient and mostly accidental - the goal was smaller files and faster delivery, and stripped metadata came along for the ride.

Why the "send as file" option changes everything

Nearly every major messaging app has a second path for sending images: as a document, a file, or "original quality," rather than through the standard photo-share flow. That path is explicitly designed to preserve the file exactly as it was, because its purpose is fidelity - sending a photo for printing, editing, or archival, where recompression would be a defect rather than a feature. Preserving the file exactly means preserving everything inside it, metadata included: EXIF, GPS if present, and whatever else was riding along, covered in full in the inventory of what a photo carries beyond GPS. If a recipient asks you to send the "original" or "full quality" version, and you comply through that path, you have very likely sent the metadata too, even if the same photo through the normal share button would not have carried it. Platform makers say as much in their own documentation. Apple's personal safety guide notes that location coordinates "are embedded into each photo and video", and that when such files are shared, recipients "may be able to access the location metadata and learn where it was taken". The same guide shows a Location switch under Options in the share sheet, which leaves the coordinates out of that share, whichever app the photo is headed to.

Why this article does not name which apps do what

App behaviour here is genuinely inconsistent, changes with app updates that happen far more often than anyone writing about them can track, and differs across platforms for the same app. A specific claim like "App X always strips GPS but keeps camera model" is the kind of statement that is true today and false after the next release, which makes it worth less than the general pattern: normal share paths tend to recompress and strip, file or document paths tend to preserve. Treating any specific claim about a specific app as current without checking is a mistake worth avoiding, on this subject more than most.

How to check for yourself

The check takes under a minute and settles the question for your actual app version rather than a claim about it. Send a test photo carrying known metadata - one you have deliberately left with GPS or camera data intact - through both the normal share flow and the file or document option, save what arrives at the other end, and inspect both with a metadata viewer. The result tells you, for that app on that device today, which path does what, which is more reliable than any general guide including this one.

Group chats and forwarding compound the uncertainty

A photo passed through several hands rarely goes through only one app. It might be captured on one phone, sent through a chat app, saved to a camera roll, then forwarded through a second app or reposted to a third, and each hop is a fresh chance for a recompression step to strip something or a file-preservation step to keep it. Forwarding within the same app sometimes reuses the already-recompressed copy rather than reaching back to any original, which is one reason a photo that has travelled through several conversations can end up smaller and more stripped than one sent once - not because anyone tried to clean it, but because each recompression pass is lossy and metadata-light by default. There is no way to reconstruct that history from the file that finally arrives; the only reliable statement is that a photo which has changed hands several times has had several independent opportunities to lose whatever it started with, and no guarantee that it lost all of it.

Where this fits

This is one of two places metadata gets handled outside your direct control - the other being the rating tool or service the photo eventually reaches, whose own practices are worth checking the same way before assuming anything. Stripping metadata yourself before sending, as covered in stripping EXIF before you upload, removes the uncertainty entirely rather than relying on an app's default behaviour to hold. None of this affects what a rating model does with the image once it arrives - scoring reads pixels, not metadata - and it has nothing to do with physical measurement, which depends on a method, not a file. If the photo is headed to a human reviewer rather than a model, the same file-versus-share distinction still applies; a reviewer sees whatever arrived, metadata and all, unless you controlled for it first.