Which Photo Metadata Survives a Download?

What this study measured

This study asked one question: of the image files a visitor with no account can download from a public page, what share still carries location coordinates, and does the copy the platform offers for display differ in that way from the file it offers for download? Two sets of files were measured on 10 Sep 2026, and neither of them is the web in general.

• Wikimedia Commons: a random sample of file pages, where every accepted file was fetched twice, once as the stored original, and once as the display copy the API points to.
• One Mastodon server: its public media timeline, where the stored full-view image, the timeline thumbnail, and any cached copy of a file sent in from another server were each fetched separately.

A file counts as carrying coordinates only when its GPS block holds a coordinate tag whose values are not all zero, and that rule was fixed before the first file was fetched. The rule matters because a camera that never got a satellite fix often writes a GPS block full of zeros, and a stripping tool that removes the value while leaving the tag produces the same result; a looser rule would have counted both as a leak. The share that follows from the strict rule is 13.7% over the originals whose coordinate tag could be read.

On the same files the run also went through the metadata block field by field, which is what the rest of this article is built on: whether an EXIF block is there at all, which it is on 59% of the Commons originals, and whether a camera make, a camera model, a serial number and a location coordinate can be read from inside it.

Nothing was decoded into the output and nothing was written to disk. The measuring program reports whether a field is present, never what it says.

The expectation, and what the measurement did instead

The pre-registration was written before the first fetch, and it predicted that between a fifth and a half of the Commons originals would carry a GPS block. The measurement came back at 13.7%, with an interval of 10% to 18.4% (the range the measurement leaves open), and that whole interval sits below the bottom of the predicted range. The registered text is recorded in the run record, and the verdict recorded against the row is that the expectation was wrong. That the prediction failed is a result of this study, not a footnote to it.

The second half of the expectation held. The pre-registration predicted that a public social timeline would be a poor place to find coordinates, because the platform re-encodes what it receives, and the measurement agreed: none of the stored image files in that sample carried a coordinate tag, and counting accounts instead of files made no difference. The contrast with the Commons original, where a real value survived in 13.7% of the files whose tag could be read, is the difference between a platform that hands back the file it stored and one that hands back a file it generated.

Which fields survive the trip

A block that survives and a field that survives are not the same thing, and that difference is where the two platforms differ. On Commons the display copy is generated from the stored file, and the generated copy keeps an EXIF block in 25.7% of files, a camera make in 1% and a camera model in 1.3%; no generated copy in that group carried a location coordinate.

On the Mastodon server the timeline thumbnail is generated as well, and it keeps an EXIF block in 98% of files while carrying no camera make, no model, no serial number and no coordinate at all. The container is the wrong thing to watch. The fields inside it are what move.

One caution belongs on the coordinate column, because it does not read the same in the table as in the chart above it. The column counts the files where the coordinate tag could be read, which is the narrower denominator, the number it divides by, that the main figure of 13.7% also uses, while the coordinate bar in the chart counts every file fetched in that group. The two numbers differ over a definition, not over a measurement, and it is the definition this run could not settle, which it records as the weakest point in the method.

The paired comparison

Pairing each original with its own generated copy is the stronger test, because it keeps the camera, the uploader and the moment the same and varies only the copy the platform hands out. Across the eligible pairs, the share of originals carrying coordinates exceeded the share of their own generated copies by 15.6 points. Pairs where the generated copy turned out to be the original under a different query string were excluded from every paired figure and counted separately, because in those pairs the two files are the same file, and they would have made the difference look smaller.

Width is not the explanation

One other explanation had to be ruled out: that the gap between 13.7% and the generated copies is a property of how small the display file is rather than of the pipeline that made it. The same generated copy was therefore fetched at two other widths, on a subsample fixed before the fetch, and neither the narrower nor the wider file carried a coordinate tag. In this sample, what was present in the file did not depend on the size the platform chose.

Two mechanisms, one result for the coordinate

The coordinate result is the same in both samples and the shape of what is left behind is not. The Mastodon server keeps the container: an EXIF block survives in 70.7% of its stored files and in 98% of its timeline thumbnails, and inside that surviving block the sample shows no camera make, no model, no serial number and no coordinate on any file. Commons does the opposite with the block itself: only 25.7% of its display copies carry one, so on most of them there is nothing left to look inside.

The second sample came from the public media timeline of one Mastodon server, drawn over sequential pages of that timeline in a single day. Two copies are reachable without an account, and both were measured: the stored full-view image, which keeps an EXIF block in 70.7% of cases, and the timeline thumbnail. The thumbnail is not an independent observation, because it is generated from the file the Mastodon server had already processed, so the run reports it as a second view of the same zeros rather than as a second sample.

The Mastodon server also keeps a cached copy of files it receives from other servers, and the pre-registration describes that copy as the closest thing in this sample to an untouched upload, because the sending server performed the first re-encode. It carried an EXIF block in 69.3% of files and no coordinate in any of them, and counting accounts instead of files made no difference.

Interpretation

One pattern, two mechanisms: the Mastodon server leaves the container in place and the Commons pipeline drops it, yet both end with no coordinate, and the only group that keeps the identifying fields themselves is the one where the platform hands back the uploaded file. Nothing in this study measures the encoder, and nothing separates a deliberate metadata policy from a setting nobody chose, so the mechanisms named above are an inference from the pattern and not a measurement of it.

If the difference between the two platforms is a single setting in the pipeline that makes the copies, then the privacy a visitor gets from a display copy is a side effect of shrinking the image rather than a decision about location data, and the serial number that survives on the original is nobody's decision at all. Testing that would mean fetching the same generated copy from a server with a different configuration and watching whether the fields come back.

Camera identity survives where coordinates do not

Of the Commons originals whose camera make could be read, 89.6% name a device from a list of consumer camera and phone vendors that was fixed before the fetch. The camera make does not say where a photograph was taken, but it does say what took it, and the list exists to separate a phone photograph from an institutional scan of a map or a painting. The display copy keeps very little of that, and the Mastodon sample keeps none of it.

The stronger identifier is one the headline question never touches. A camera serial number is written by the camera and belongs to that one camera, so where it survives it links photographs taken by the same camera, across years, across owners and across websites, and it does so without naming a place at all. In this sample it survives on a smaller share of files than the coordinate does, at 12%, and is the stronger identifier of the two.

The generated copies keep almost none of it. A camera make survives in 1% of the Commons display copies, a model in 1.3%, and a serial number in none of them. Every field count here is the lowest it could be rather than the true share, because it divides by all the files fetched in that group, so the true shares behind 49% and 55% can only be higher. The field records what the camera wrote, not who was holding it.

How the measuring program was checked

Every number here rests on a program that reports whether a field is there and never what it says, so the run spent effort proving that program can see what it claims to see. It was calibrated before the first real fetch, on 12 test files built for the purpose: every container format the samples contain, in a stripped version and a version that carries a coordinate, plus files whose metadata sits past the fixed window the program reads.

If that calibration had failed, the run would have stopped instead of publishing.

• Reading whole files was too expensive at this scale, so each file was read through a fixed window at the start, with a second request for the end of anything large enough to have one.
• A tenth of the accepted files were downloaded whole and parsed whole, and the start of the file never disagreed with the whole-file read over the files that were checked.
• The end of the file never recovered a coordinate that the start had reported absent, over the comparable pairs.

The measurement was then repeated by a second program, written separately, on the same input list. It reached the same conclusion about the expectation that failed, and both datasets agree wherever the run says they agree.

They do not print the same share for every group, and the difference is in the definition rather than in the data: the second run divided by a wider denominator, which is why the claim this article opens with carries more than one reported number and why 13.7% is the narrower of them.

Where this measurement is weak

The numerator was fixed in advance; the denominator never was, and that is the weakest point in the run. The method says which files count as carrying coordinates and never says which files count as the sample, so the replication counted every row that was neither discarded nor a file the program could not read, while this run counted only the rows where the coordinate tag could be read, which is the denominator behind 13.7%.

The run record carries both numbers, and the expectation failed under either. A reader comparing them is looking at a difference in definition, not at a disagreement about the data.

The field counts carry one limit more than the coordinate count does. A coordinate is counted over the files where its tag could be read, while a field is counted over every file fetched in the group, so a file whose metadata the program could not read counts against the field instead of being left out as unmeasured. 59% is the lowest it could be for that reason, and the true share can only be higher.

What would change the answer

Several things would change this result, and the obvious candidate is not among them.

• A platform stops generating a copy and serves the stored file directly, which closes the gap between 13.7% and the generated copies.
• The pipeline that makes the copies is set to carry the fields forward, which flattens the chart above instead of leaving it steep.
• An upload path stops writing coordinates at all, which takes the original share down toward the Mastodon numbers.
• The reader is looking at a source this run never measured, because two sets of files are not the web.
• What would not change it is a larger sample from the same sources: more files would narrow the interval around 10% to 18.4%, and the expectation failed on where the measured value sits, not on how narrow the interval is.

What Viallo does with the file you upload

Viallo is built the same way as the one group in this study where coordinates survived at a meaningful rate. The file you upload goes into storage as it arrived and the download button returns that stored file, so what a recipient downloads is what the camera wrote, which is the same setup that leaves the Commons original at 13.7% while the copy the page displays carries nothing.

• The stored original is not cleaned: a JPEG, PNG or WebP is written to storage at the resolution and file size it arrived in, nothing is re-encoded on the way in, and the download button on a shared photo returns that file.
• HEIC is the one conversion, and the one place fields are lost: an iPhone HEIC or HEIF photo becomes a JPEG at full pixel dimensions, and the metadata does not survive that conversion, which is why the upload path reads the camera's fields before the conversion rather than after it.
• The smaller copies do lose their metadata: the display copy and the thumbnail are generated without the flag that carries metadata forward, and both are rotated so that orientation is baked into the pixels instead of written in a tag.
• The location is read on purpose: the coordinate is extracted at upload and used by the map, so reading it is a product feature rather than a side effect.
• Stripping exists in one place: the time capsule removes metadata from a file before a sealed capsule is stored, and it is the only path in the product that does.

Interpretation

That is a deliberate trade-off rather than an oversight, and it is worth saying so plainly. Keeping your files exactly as they are is what the product is for. A photo library that quietly rewrites your files would be a worse photo library, and keeping the file as it arrived is what makes the download worth having.

The practical consequence is the one the Commons part of this study points to, where 13.7% of originals still carried a coordinate when they were downloaded. A file you would rather not hand over with its coordinates and its camera serial number attached has to be cleaned before it reaches Viallo, because Viallo will keep it exactly as you sent it.

Sources

Neither platform documents what happens to metadata in a copy it generates. The pages below say what the metadata is for and where it lives; what a generated copy keeps is what this study had to measure.

• MediaWiki, API:Imageinfo. Documents iiurlwidth and the thumburls property this study used to pick the display copy, and records that the returned thumbnail URL is not guaranteed to match the requested width. mediawiki.org/wiki/API:Imageinfo
• Wikimedia Commons, Commons:EXIF. Says that metadata travels inside the file and that a photograph carries location coordinates if the device has a GPS receiver. It says nothing about what a generated thumbnail keeps. commons.wikimedia.org/wiki/Commons:EXIF
• Mastodon, server configuration reference. Names the image library used to process uploads and says nothing about metadata being removed, which is what this study saw on every field that identifies the camera. docs.joinmastodon.org/admin/config
• Wikimedia Phabricator, T360589. The change that rounds a requested thumbnail width up to a preset step. It is why the width comparison above shows two different files rather than two exact sizes. phabricator.wikimedia.org/T360589

Every source above was read on 10 Sep 2026, the day the files were fetched.

The data behind this article

Everything above comes from the same table, and it is published so anyone can check it or reuse it.

• The measurements. One row per fetched file, one column per measured field, and every field a yes or no. It carries no image content, no coordinate values, no serial numbers and no account names, and the identifiers for the Mastodon files are salted hashes whose salt is not published, so a row cannot be traced back to an account. DATASET.csv
• The run and the instrument. Where each sample came from, how the reading program was checked, and the counts per group. DATASET.json
• The prediction, written first. The question, the predicted share and the counting rules, all fixed before the first file was fetched. PREREGISTRATION.md
• Licence. Released into the public domain under CC0, so it can be copied, changed and reused for any purpose without asking. LICENSE.txt
• The program that read the files. It requested each accepted address, read the metadata block out of the bytes that came back, and wrote one row per request. MEASURE.mjs
• The analysis. It turns the measured rows into the shares and intervals this page reports, with nothing typed in by hand. ANALYSE.mjs
• The re-execution. An independent second driver written against the pre-registration, and the report of where the method and the run disagree. REPLICATE.mjs and REPLICATION.md
• The dataset page. The published data, its licence and the citation in one place, for anyone who wants to cite it rather than read it. /studies/downloaded-photo-location-metadata

Frequently Asked Questions