TL;DR: No — Google Photos does not strip EXIF from the originals in your library. Download a photo you uploaded at Original quality and the EXIF block comes straight back: the GPS IFD with your latitude and longitude, the camera Make, Model and Software, the DateTimeOriginal timestamp and the embedded thumbnail. There are two real exceptions, and both are narrower than people assume. When you share by link, Google can drop the GPS coordinates from the downloadable copy if the "Remove geo location" setting is on — but only the GPS, not the rest of the EXIF. And a Google Takeout export moves dates and locations into separate .supplemental-metadata.json sidecar files rather than guaranteeing they sit inside each image. So "it's in Google Photos" is not the same as "it's clean." To actually remove metadata, strip it before you upload.
Does Google Photos remove EXIF data?
For the photos sitting in your own library, the answer is no. Google Photos is built to preserve your originals, and metadata is part of the original. Upload a JPEG and download it again at Original quality, and the APP1 segment that begins with the bytes Exif\0\0 comes back intact — the same DateTimeOriginal, the same camera Make and Model, the same nested GPS IFD holding the latitude and longitude where you stood. Google leans on exactly this data to build the features people use it for: the map view, the "on this day" memories, and search-by-place all read the location and timestamp out of your files. Stripping that data would break the product, so it keeps it. If you have never looked at these fields directly, our primer on what EXIF data actually is lays out what a camera writes into every frame.
The one place the picture changes is the backup quality setting. Original quality stores the file byte-for-byte, metadata and all. Storage saver — the option formerly called High quality — re-encodes anything above 16 megapixels down to 16MP to save space, and that re-compression is its own pass over the file. It changes the pixels, and depending on the pipeline it can drop or rewrite some tags. But you should not treat Storage saver as a privacy feature: its job is to shrink the picture, not to scrub the record attached to it, and the GPS coordinates are exactly the kind of field that tends to survive a re-encode. Google documents the difference between the two tiers on its own backup quality help page, and "smaller file" is never a reliable proxy for "no metadata."
Photo by BM Amaro on Pexels.
What does Google Photos do with location data when you share?
This is where the "Google removes it for me" belief comes from, and there is a kernel of truth in it. When you share a photo through a Google Photos link, Google can remove the GPS coordinates from the copy the recipient downloads. The behavior is governed by a setting — "Remove geo location in items shared by link" — and Google describes how the feature protects location on its location-data help page. When it is active, the person who saves your shared photo gets a file with the latitude and longitude taken out.
Read that carefully, because the limits matter. First, it is scoped to location — the GPS IFD specifically. The camera Make and Model, the lens, the Software field, the DateTimeOriginal and the embedded thumbnail are not what this setting touches, so they travel to the recipient unchanged. Second, it applies to the link-share flow, not to everything. Shared Albums behave differently: people you have invited can see the place a photo was taken, and a member who downloads an item out of a shared album may get a file that still carries its location. And the original in your own library is untouched throughout — the setting changes what leaves through a link, not what Google holds. If your goal is to hand someone a photo with no embedded coordinates at all, our walkthrough on how to send photos without location data covers the dependable ways to do it, and our explainer on how GPS coordinates get embedded in photos shows why that one tag is the stubbornest of the lot.
It is worth contrasting this with how a social platform handles the same problem. Instagram re-encodes every upload and discards EXIF as a side effect of its pipeline, which we documented in does Instagram actually remove EXIF data. Google Photos is the opposite by design: it is a library that keeps your metadata and only removes a single field, conditionally, on one sharing path. Neither approach is something to lean on, but they fail in different directions.
Why does a Google Takeout export scatter metadata into JSON files?
If you have ever exported your library through Google Takeout, you have met the most misunderstood part of this whole question. A Takeout archive does not always carry the full metadata inside each image. Instead, Google writes a companion JSON file next to every photo — renamed in late 2024 from the old IMG_1234.jpg.json form to IMG_1234.jpg.supplemental-metadata.json — and puts the authoritative date taken, GPS location and description in there.
The reason is architectural. Google Photos stores a lot of metadata in its own database rather than only in the file: a location you corrected by hand, a date Google inferred for a scan, a description you typed. That database metadata was never written back into the image's EXIF, so when Takeout assembles your export it dumps that information into the sidecar JSON to avoid losing it. The practical result trips people up constantly: the exported .jpg can show a wrong or missing date and no coordinates when you open it in another app, while the real values sit unread in the .json beside it. Delete the JSON without merging it back and that metadata is gone for good. This is the same sidecar pattern we describe in what a sidecar file is — metadata living in a second file beside the image, where anything you do to the photo alone never touches it.
There is a privacy reading of this that cuts against the usual panic. A Takeout image whose GPS lives only in the sidecar is, on its own, a file with no embedded coordinates. But this is an accident of how Google exports, not a cleaning step you can trust: re-encode that image through certain tools and the database never mattered; download the same photo a different way and the EXIF is fully populated. You cannot predict which version of your file you are holding, which is the whole problem with relying on a platform's quirks instead of controlling the file yourself.
What does Google Photos never remove?
Set the location question aside and look at the rest of the EXIF block, because even in the cases where Google drops your GPS it leaves a surprising amount behind. The camera Make and Model identify the device. The Software tag records the app or firmware that last wrote the file. DateTimeOriginal pins the capture to the second. On many phones the MakerNote — a manufacturer-specific blob inside APP1 — carries a device serial number or lens identifier, and the embedded thumbnail Google stores can still show the uncropped original frame even after you have cropped the visible image. None of that is "location," so none of it is what the share setting removes.
That is the honest limit to state plainly: Google Photos protecting your location is not Google Photos cleaning your photo. The EFF's work on privacy makes the broader point that metadata is a category, not a single field, and that the fields people forget about — the timestamp, the device fingerprint, the serial number — are exactly the ones that link a "clean" photo back to a person or a camera. A copy with the GPS gone and the serial number intact is not anonymous; it is just missing one of several identifiers.
Photo by Darlene Alderson on Pexels.
How do you make sure a photo carries no metadata before Google Photos sees it?
Stop trying to make a storage product double as a privacy tool. The reliable move is to remove the metadata yourself, before you upload, so that whatever Google keeps or strips no longer matters — the file you handed it never carried anything to begin with.
Strip the metadata with a tool built for it. Open Metadata Cleaner in any browser and drop in the photo. It performs a container rewrite — it copies the image data into a fresh file and omits the APP1, APP13 and comment segments — so the EXIF, the GPS IFD, the IPTC and XMP packets, the MakerNote and the embedded thumbnail all come out, while the visible pixels stay byte-for-byte identical. The work runs locally in your browser; the photo is never uploaded to us. The mechanics of that lossless rewrite are the subject of our deeper piece on how metadata scrubbing works, and if you would rather do it inside the operating system, our cross-platform guide to stripping EXIF data from a photo covers Mac, Windows and iPhone.
Then upload the cleaned copy. For anything you intend to share by link, turn on Google's "Remove geo location in items shared by link" setting as a second layer — it costs nothing and removes the GPS from link downloads — but treat it as a backstop, not the plan, since it leaves every non-location tag in place. And whatever route you took, verify the file you are actually about to send: re-open it and confirm no EXIF, GPS or XMP fields remain. One caveat worth knowing if your library is full of iPhone shots: the format matters too, because HEIC stores EXIF inside a meta box rather than an APP1 marker, which our HEIC versus JPEG comparison walks through. The cleaner handles both, but it is a reminder that "where the metadata lives" changes with the file type.
Google Photos is a good place to keep your pictures and a poor place to clean them. It preserves your originals on purpose, removes a single field on one sharing path, and scatters the rest into JSON when you export. Control the file before it gets there and none of those behaviors are something you have to memorize.
Try Metadata Cleaner free — strip EXIF, GPS, IPTC, XMP and the embedded thumbnail from any image, video or audio file, locally in your browser, with nothing uploaded.