The short answer
Do not rely on a general claim that a social platform always removes all photo metadata; prepare and inspect the local sharing copy first. The service still receives the upload, may create several derivatives, and may handle original files or metadata differently from what visitors can download.
The distinction is useful for public posts, private messages, marketplace images, profile pictures, group albums, and creator publishing tools.
Public derivative behavior is not the whole data path
A service may resize an image and omit metadata from the version other visitors see or download. That observation concerns a derivative, not necessarily the uploaded original, internal processing copy, abuse-review system, backup, or message attachment. The platform receives the file before transforming it, so sensitive metadata can still cross the boundary even when it is absent from a public rendition.
Different upload surfaces inside one service may use different pipelines. A profile picture, marketplace listing, direct message, cloud album, and creator tool may not behave alike. Mobile and web applications can also prepare files differently before transfer. Because these systems evolve, a test from last year or a statement about one surface should not be generalized to every current use.
Prepare locally, then configure the destination
Local preparation gives you control over the input: inspect, remove supported fields, verify, and retain the cleaned copy you actually submit. It does not control the service after submission, but it reduces the metadata included in the initial file. This is especially useful when the destination’s documentation is unclear or when a recipient may download and redistribute the original attachment.
After preparing the file, review current audience controls, discoverability, resharing, download, retention, and deletion settings at the destination. Consider captions, tags, check-ins, account names, and comments because they can recreate the same disclosure the metadata cleaning was intended to avoid. For private messaging, remember that recipients can still save, forward, screenshot, or describe visible information.
Use the browser tool on the final file
Inspect and clean the intended copy locally, verify it, and then review the destination service’s current audience and privacy settings. Choose the exact JPEG, PNG, or WebP copy you intend to share and select Inspect metadata. Read the grouped results and distinguish removable findings from retained color information. If removal is appropriate, create a cleaned copy. The tool rewrites supported container metadata without canvas recompression, reparses its output, and enables download only after verification reports no supported removable metadata.
Keep the original separately, download the “-clean” copy, and inspect that downloaded file again when the decision is sensitive. This workflow gives evidence about one exact file; it does not alter earlier exports or copies already sent elsewhere. The selected bytes and parsed values stay in the current browser tab rather than being uploaded to an image-processing endpoint.
Interpret the result within its scope
A locally verified result provides evidence about the file you submitted, not about every server-side copy, log, derivative, backup, or later download. Platform interfaces, documentation, and processing pipelines change, so this guide intentionally avoids permanent claims about named third-party services.
A clean result is deliberately narrow: it means the parser did not find a supported privacy-sensitive or removable item in that file. It is not proof against every proprietary block, concealed payload, visible clue, filename disclosure, remote copy, or steganographic technique. Review pixels, context, audience, and destination separately, and use a purpose-built forensic workflow for high-risk decisions.