Does Google Drive Remove EXIF Data? We Read Google's Field Documentation

Short answer: Google’s own documentation shows Drive reading and exposing EXIF values — including the GPS location and the EXIF DateTime stored in your photo. What the documentation does not say is whether the file you download later is byte-for-byte the file you uploaded. We did not run that test on Drive, and this page does not claim we did.

The Drive API File resource has an output-only imageMediaMetadata object. Google describes one of its fields as “The date and time the photo was taken (EXIF DateTime)” and another as “Geographic location information stored in the image”. Drive also treats photos as blob files — raw binary files — and downloads them with alt=media. Neither document contains the words “strip” or “remove EXIF”, and neither promises the uploaded bytes come back unchanged. So the honest conclusion is narrower than a yes or no: Drive demonstrably reads your metadata; whether a round trip preserves the original EXIF block is not answered by these documents, and would need an upload-and-download byte comparison we did not perform.

What we documented, and what we did not test

This article is a documentation-only entry in the series. Keeping the boundary visible is the point.

Documented. We fetched and quote three primary pages, all linked below: the Google Drive API File resource reference, the Google Drive API download-and-export guide, and the Stack Exchange API response for one third-party answer. Every sentence in quotation marks on this page was read from those sources on 2026-11-04.

Not tested. We did not log into Google Drive, did not upload an image, did not download one, did not compare hashes, and did not inspect what the Drive web interface, Backup and Sync, Drive for desktop, or a shared link does. 本机未实测 is the rule for this entry: no number on this page is a measurement of Drive. Claims about any Google service UI are labelled as inference, not observation.

Why keep writing entries like this? Because the baseline question — do screenshots have exif data — is about which metadata exists in the first place. Once you know the fields, the next question is always which piece of software rewrites the file. Documents can tell you what a system is designed to expose; they cannot tell you what bytes came out of a specific round trip.

The exact words in Google's File resource

The File resource reference describes an output-only object named imageMediaMetadata. The field table says, verbatim: “Additional metadata about image media, if available.” It then lists sub-fields one by one. These are the ones that matter for a privacy question:

“imageMediaMetadata.time string Output only. The date and time the photo was taken (EXIF DateTime).”
“imageMediaMetadata.location object Output only. Geographic location information stored in the image.”
“imageMediaMetadata.location.latitude number Output only. The latitude stored in the image.”
“imageMediaMetadata.cameraMake string Output only. The make of the camera used to create the photo.”

Read literally: Google names EXIF in its own field description, and says the location is stored in the image. That is a documented statement that Drive reads values out of the photo and surfaces them through its API. It is not a statement about what happens to the file bytes afterward.

Also note “Output only”: the object is generated by Drive, not supplied by the uploader. It is an index of what Drive found, not a copy of the original EXIF block you could edit through the API.

How Drive stores and returns image data

The download guide defines what an image is to Drive. Verbatim: “In the Drive API, a blob file refers to any raw binary file stored on Google Drive (such as images, videos, and PDFs) as opposed to a Google Workspace document.” It then says that to download one you use files.get with the alt=media parameter, and that Python callers can “access the raw bytes” from the returned stream.

So the documented model is a binary blob in, a binary blob out. There is no documented image-decoding step in that path, and no mention of a re-encode on download. That is a meaningful design fact about the API.

It is still not a guarantee. We checked the page for a promise of byte identity and did not find one. The word EXIF does not appear on the download guide at all; “metadata” appears only inside OAuth scope names and restriction field names. An absence of a documented re-encode is not evidence that no re-encode ever happens in any Drive entry point.

What the documentation does not say

Three gaps are worth writing down, because most confident one-line answers to this question sit exactly in them.

No promise of identical bytes. Neither page says the downloaded file is the same byte sequence as the uploaded file. Without that sentence, a documentation-based answer cannot claim the EXIF block survived intact.

No statement about stripping. Neither page uses “strip” or says metadata is removed. The imageMediaMetadata table in fact points the other way: it describes values read from the image.

No coverage of the consumer paths. The docs describe the API. They say nothing about Drive’s web preview, thumbnail generation, “open with” handoffs, shared-link viewers, or what a recipient’s browser downloads. Those are the paths most people actually use, and they are outside everything we verified here.

A page that answers “yes, Drive strips EXIF” or “no, Drive keeps everything” from these two documents is filling those gaps with an assumption.

A third-party report, and why we rank it low

One older Stack Overflow question asks about changing photo dates in Drive. Fetching the answer through the official Stack Exchange API returned a single answer, created 2015-11-01, score 0, not accepted. Its author writes, verbatim: “The EXIF metadata is in the header of the jpeg file, i.e. in the GooDrive universe it is inside of the file content.” and then “It is my belief that GooDrive reads this content ... and saves/indexes jpeg metadata to it’s own copy”.

We include it for completeness, not as proof. It is one person’s belief, explicitly labelled as such by its author, with no votes and no acceptance. It is consistent with the official imageMediaMetadata field, but a consistent guess is still a guess. The web version of that question returned only a “Just a moment...” challenge page when we tried to read it directly, which is why the quote above comes from the API response instead.

So does Google Drive strip EXIF? The honest answer

What we can state from the documents: Drive parses values out of photos, including the EXIF DateTime and the geographic location stored in the image, and exposes them as read-only metadata on the File resource. Drive’s API models photos as raw binary blobs and downloads them as blob content.

What we cannot state: that an upload/download round trip returns byte-identical EXIF, or that some Drive entry point never re-encodes an image. No page we read says either thing. This is the same boundary as do screenshots have exif data: knowing which fields exist is not the same as knowing what a specific pipeline did to them.

Inference, clearly marked. Based on the measurements in our own earlier entries, we would expect metadata loss to come from a step that decodes and re-encodes the image — a resized preview, a compressed “storage saver” upload, or a screenshot — rather than from a blob transfer. That is an extrapolation from our WhatsApp compression test and our Telegram client-source test, not a measurement of Drive. We did not test Drive, so we do not grade Drive on it.

If you need a real answer for your own account, the test is cheap: upload a JPEG with known EXIF and GPS, download it with alt=media, and compare the SHA-1 of both files. We describe that comparison method in our email byte-for-byte test; we simply did not run it against Drive for this article.

Where EXIF loss usually comes from

Across this series, the variable that changed the outcome was never transport. It was whether something decoded the JPEG into pixels and wrote a new JPEG.

In our Discord reproduction, an explicit strip step removed every EXIF field while leaving independent XMP and IPTC segments readable. In the WhatsApp test, standard and HD quality both produced zero metadata blocks; only the path that sent the original file bytes preserved them. In the email test, a base64 MIME attachment came back byte-for-byte identical with all 14 EXIF fields, while resizing the image first removed everything.

That pattern is why we treat “does this service strip EXIF?” as the wrong first question. The better one is: did anything re-encode the file, and can I compare the bytes? None of those three measurements involved Drive, and none of them is offered here as evidence about Drive.

How to check your own Drive file

If you have a Drive account, you can settle this for yourself in a few minutes without trusting any article, including this one.

1. Make a JPEG with known fields — camera model, date, and GPS. 2. Note its size and SHA-1. 3. Upload it. 4. Download it as the original file, not as a preview or an exported image. 5. Compare the hash. If it matches, the file is byte-identical and every metadata segment in it is intact. If it does not, inspect the EXIF, XMP and IPTC blocks separately with ExifTool.

A mismatch alone does not prove stripping: a service could rewrite container bytes while carrying the metadata across, or return a different resolution. You have to read the fields to tell. Our guide to viewing EXIF data walks through that inspection, and the baseline do screenshots have exif data explains what a screenshot typically contains in the first place.

Sources and how we sourced them

All three sources were fetched on 2026-11-04 and linked below so you can re-read them.

Drive API File resource reference — fetched as HTML and searched for the imageMediaMetadata field table; the quoted field descriptions come from that table. Drive API download-and-export guide — the blob definition, the alt=media download description and the “access the raw bytes” line come from this page. Stack Exchange API answer response — used because the ordinary question page returned an anti-bot challenge instead of its content.

Two things we could not use: Google Drive Help article 2424364 returned “Sorry, this page can’t be found.”, so we do not cite it; and the ordinary Stack Overflow page returned only “Just a moment...”. Neither is used as evidence. We also found no sentence in the two official pages that promises byte-identical round trips or mentions EXIF removal, so no such claim appears above.

FAQ

Does Google Drive remove EXIF data? The official documentation does not say that it does. It documents Drive reading EXIF values such as the EXIF DateTime and the GPS location stored in an image and exposing them as read-only File metadata. It does not document a stripping step. We did not test Drive itself, so we cannot confirm what a downloaded file contains.

Does Drive keep GPS coordinates from my photos? The File resource has an imageMediaMetadata.location object described as “Geographic location information stored in the image”, with latitude, longitude and altitude sub-fields. That is a documented API field, not a measurement of your account.

Is the file I download from Drive byte-identical to what I uploaded? We found no official statement guaranteeing that. The download guide describes blob files and raw bytes, but does not promise identity. The only way to know for your file is to compare hashes.

Did you test this yourself? No. This is a must-cite documentation entry: we did not upload, download or hash any file in Drive. Every factual claim here is tied to a linked source, and anything else is labelled as inference.

What does Output only mean on those fields? Google marks imageMediaMetadata and its sub-fields as output-only, meaning Drive generates them and an API client cannot set them directly. They are an index of values Drive read, not an editable copy of the EXIF block.

What is a blob file in Drive? The download guide defines it as “any raw binary file stored on Google Drive (such as images, videos, and PDFs)”, as opposed to a Google Workspace document. Photos fall in this category.

Should I strip EXIF before uploading? If location privacy matters, removing metadata locally before upload is the only step you fully control. Our guide on erasing EXIF data covers that. Do not assume a cloud service will do it for you.

Why not just give a yes or no answer? Because a yes would require a round-trip byte comparison we did not run, and a no would require a guarantee we could not find in the docs. The verifiable answer is narrower: Drive demonstrably reads EXIF; what it returns on download is not established by these documents.