Screenshot vs Original Photo: What Metadata Actually Survives

How we tested it (one photo, one real screenshot, no simulation)

Most comparisons on this topic are theoretical: somebody lists what EXIF contains and asserts that a screenshot drops it. We did the byte work instead, on 2026-11-01, with Pillow 12.3.0, piexif 1.1.3 and Chrome 156 on Python 3.13.

Step 1. We wrote a 1200×800 JPEG and attached 47 EXIF fields across four IFDs: 16 in IFD0, 20 in the Exif sub-IFD, 9 in GPS, and 2 in IFD1 (the embedded thumbnail's offset and length). The file came to 42,890 bytes, of which the APP1 segment was 2,194 bytes.

Step 2. We rendered that photo in a real browser at its native size (1200×800, device scale factor 1, margins zeroed) and captured the frame buffer with Chrome's screenshot path. The result was a 13,064-byte PNG.

Step 3. We parsed both files at the container level: JPEG marker segments on one side, PNG chunks on the other. Then we read EXIF three independent ways (piexif, PIL.Image.getexif, and Image.info) and compared the decoded pixels of the two files one by one.

Nothing below is quoted from documentation. Every number is from that run.

The original: 47 fields inside one 2,194-byte APP1 segment

The source file's segment order was APP0 (16 B), APP1 (2,194 B, Exif header), DQT, DQT, SOF0, DHT ×4, SOS. All 47 fields live in that single APP1 block. The headline values:

• Who made it: Make Canon, Model Canon EOS R5, Software Adobe Lightroom 13.0 (Windows).
• Who owns it: Artist Wei Zhang, Copyright (c) 2026 Wei Zhang. All rights reserved.
• Where it was: GPS 31°13′23″N, 121°28′12″E, altitude 7 m, timestamp 2026:05:12 06:03:21 UTC.
• When: DateTime, DateTimeOriginal and DateTimeDigitized, all 2026:05:12 14:03:21.
• How: f/2.8, ISO 400, 1/200 s, 35 mm (35 mm equivalent 35), metering mode 5, flash 0, exposure program 2.
• Which body and lens, uniquely: BodySerialNumber 032021004567, LensSerialNumber 0000c1a9b2, LensModel RF24-70mm F2.8 L IS USM.
• Print intent: XResolution and YResolution both 300, ResolutionUnit 2 (inches).
• A second copy of the picture: IFD1 holds a JPEG thumbnail at offset 1,042, 1,144 bytes long.

Two serial numbers plus a GPS fix is the worst case for privacy, which is why we built it that way.

The screenshot: five chunks, zero fields

The captured PNG was 13,064 bytes with exactly six chunks: IHDR (13 bytes), four IDAT blocks of 4,096 bytes plus a 665-byte tail and a 6-byte closer, and IEND. That is the entire container.

Read three ways, EXIF came back empty every time:

• piexif.load() raised “Given file is neither JPEG nor TIFF” — a PNG has no APP1 segment for it to read.
• PIL.Image.getexif() returned 0 entries.
• Image.info was an empty dict — no DPI, no ICC profile, no gamma, no transparency key.

So the 300 DPI print intent, the orientation flag, the two serial numbers, the GPS fix and the 1,144-byte thumbnail did not get corrupted or partially copied. They had no place to be written, and nothing tried to write them.

The full comparison, field by field

All 47 fields from the original, against what the screenshot returned for each one. “absent” means the reader had no such field, not that the value was blank.

47 in, 0 out. Two of them — ExifImageWidth and ExifImageHeight — are marked differently because the screenshot does answer those questions, just from IHDR instead of from EXIF. The number is preserved; the field is not.

The pixels are identical, and that is the unsettling part

We compared all 960,000 pixels of the two files: 0 pixels differed, maximum channel difference 0. The screenshot is not a lower-quality version of the photo. As far as the image data goes, it is the same picture.

That is exactly why the metadata loss is easy to miss. Open both files side by side and you see one image twice. The difference lives entirely in the first 2,194 bytes of the original — the part no viewer renders.

One honest caveat about file size: the source was 42,890 bytes and the screenshot 13,064 bytes, but that 69.5% drop is not a general rule. Our test image is large flat colour with thin grid lines, which PNG compresses almost perfectly and JPEG handles poorly. On a real photograph, a PNG screenshot is normally larger than the JPEG it came from. Do not read this pair as “screenshots save space.”

What the screenshot does keep

Three things, and only three:

• Dimensions: 1200×800, now stated in IHDR instead of in ExifImageWidth/ExifImageHeight.
• The pixels: unchanged, as measured above.
• The format: PNG, which is a different container with a different (much smaller) set of optional fields.

Not kept: the 300 DPI print intent. The screenshot had no pHYs chunk at all, so it reports no DPI rather than 300. Also not kept: the sRGB ColorSpace tag. Chrome's screenshot path wrote no iCCP, sRGB, gAMA or cHRM chunk, which we measured separately in our screenshot colour profile test. And not kept: the orientation flag, which matters because a screenshot is already rendered upright — there is nothing left to rotate.

So is a screenshot a safe way to share a photo?

For privacy, it is the most thorough scrub available, and it requires no tool: the camera model, both serial numbers, the software that edited it, the author name, the copyright line, the exact GPS fix and the hidden thumbnail are all gone in one keystroke.

The costs are real too. You lose the ability to prove authorship or copyright from the file. You lose the capture timestamp — the screenshot records when you captured the screen, not when the photo was taken, and in our test even that did not survive into the file. You lose print resolution. And you lose the original JPEG encoding: a screenshot re-encodes the decoded pixels into PNG, so any later JPEG save is a second lossy generation.

If the goal is only to remove GPS while keeping the photo's provenance, a metadata strip is the better tool — it edits the container instead of rebuilding the image. We measured that path in how much space does stripping metadata save, where the pixels also came out bit-identical. And if you are wondering whether the dropped fields can ever be recovered, they cannot: can you recover EXIF from a screenshot walks through why, field by field.

A screenshot of a photo is not a copy of a photo

This is the distinction that trips people up, and it has its own page because it is a different question: does a screenshot of a photo keep EXIF. Short version: no, and the mechanism is the same one measured here — the compositor hands the encoder finished pixels, and finished pixels carry no history.

It also means a screenshot cannot be used as evidence that a photo was unedited. The EXIF that would show an editing history is exactly the part that does not survive. What a screenshot proves is what was on screen at that moment, nothing about the file behind it. For the device-level version of that argument, see do screenshots contain device info.

FAQ

Does a screenshot keep the original photo's EXIF? No. We measured 47 EXIF fields in the source and 0 in the screenshot of it. A PNG has no APP1 segment, so there is nowhere for EXIF to be stored.

Does a screenshot lose image quality? Not in our test. All 960,000 pixels were byte-identical with a maximum channel difference of 0, because the screenshot captures the already-decoded pixels losslessly into PNG.

Is a screenshot smaller than the original photo? Usually larger, not smaller. Our 42,890-byte JPEG became a 13,064-byte PNG only because the test image was flat colour. Real photographs compress far better as JPEG.

What metadata does a screenshot keep? Dimensions (from the PNG header) and the pixels. It drops camera, lens, serial numbers, GPS, timestamps, author, copyright, DPI and the embedded thumbnail.

Can I tell from a screenshot which phone took the photo? No. The model and serial number fields are gone. Screen size can hint at a device class, which is a different and much weaker signal.

Is a screenshot safer to post than the photo? For metadata, yes — it removes everything at once. But it also destroys the provenance, and it changes the encoding, so keep the original somewhere if authorship might matter later.

Does taking a screenshot of a screenshot change anything? It removes the little that was left. A screenshot of a screenshot has the same five or six chunks and still no EXIF, so nothing further is lost.

Related reading

If you are deciding between sharing a screenshot and sharing the photo, these are the next reads:

• do screenshots have exif data — the main guide: everything a screenshot carries, and everything it drops.
• Does a screenshot of a photo keep EXIF? — the same question asked the other way round, with the mechanism explained.
• Can you recover EXIF from a screenshot? — why the missing fields cannot be reconstructed, and what can be inferred instead.
• Why your screenshot says 119.99 DPI — the one metadata value a screenshot does write, and where it comes from.