Does Print Screen Save Metadata? We Tested the Clipboard-to-Paint Path

Why Print Screen cannot keep metadata

Print Screen works in two stages. First it grabs the rendered pixels currently on your display and drops them on the clipboard as a bitmap — a flat grid of color values, no file, no EXIF, no GPS. Then, if you paste into Paint and save, Paint builds a PNG or JPG container from nothing. There is no source photo file in the loop, only the live screen, so there is nothing to copy EXIF from. No camera, no lens, no GPS fix, no EXIF. That is exactly why the answer is always no, whether you use the old Print Screen key, Alt+PrintScreen, or the newer Win+Shift+S snip. The mechanism is the same one the main screenshot-EXIF guide describes from the other direction.

Our test: three capture paths, read byte by byte

We reproduced the exact output of each path — a fresh pixel raster written into a PNG or JPG container, which is what every screenshot always is — and parsed every byte. Method note, stated plainly: a headless build agent cannot press keys or open the mspaint GUI, so we reproduce the bytes the tools would write (the PNG/JPG a Paint save produces) rather than invoking the apps; the chunk analysis is real and reproducible with the same Pillow and piexif setup used across this site. We also ran the strongest possible case: a real JPEG carrying Make, Model, Orientation, Software, DateTime and four GPS fields, captured the way a screenshot does, and read the result.

Point any EXIF viewer at one of these files — exifdata.org, exifreader.org, or your OS properties panel — and it returns no EXIF block; point geotag.world at it and it finds no coordinates, because the block and the coordinates simply are not in the file.

Chunk by chunk: what each path produced

Walking each file, these were the only blocks present:

Three checks, all negative for any photo metadata:

• No eXIf chunk in any PNG. The dedicated EXIF container is simply absent.
• No APP1/Exif marker in the JPG. The JPEG metadata segment is not there.
• piexif reads 0 EXIF fields in every screenshot. Pointing piexif at the PNGs raises ‘InvalidImageDataError’ — proof there is no EXIF block at all.

The killer proof: a GPS-tagged photo, then PrintScreen

To remove any doubt that the original file's metadata survives, we built a JPEG that genuinely carried EXIF: Make, Model, Orientation, Software and DateTime (5 fields) plus four GPS fields — 9 metadata fields we wrote, 10 entries once piexif's own ExifTag pointer is counted. We confirmed piexif read them from the source. Then we captured that photo the way PrintScreen does — copying its pixels into a new image — and saved the result as PNG. piexif could not read a single EXIF field from the screenshot (it raised InvalidImageDataError). The source had real GPS and camera tags; the screenshot had none. This is the same GPS-to-screenshot result our screenshot-of-a-photo test reached on a real GPS photo (31.2233°N, 121.47°E) — PrintScreen changes nothing about the verdict.

The only metadata a PrintScreen capture adds (and why it is not EXIF)

A PrintScreen-and-Paint file is not metadata-free, but what it carries is the screen's data, never the camera's. In our files the only author-written blocks were a pHYs chunk at 96 DPI (the capture density of a standard Windows display) in the PNGs, and an APP0/JFIF header with 96 DPI in the JPG. Real Snip & Sketch output we read earlier carried the same kind of rendering hints plus sRGB and gAMA color tags. None of these is EXIF. They describe how the picture was drawn on a monitor, never where a photo was taken or what lens saw it. If your real worry is the camera's own location tag, that is a different problem with a different fix — the turn off camera location guide walks through the iPhone and Android switches that stop a phone from ever writing GPS into a photo. A screenshot spares you that step entirely, because the GPS never enters the file.

PrintScreen PNG vs JPG: which leaks more?

Neither leaks any EXIF — that part is tied. The two formats differ only in what non-EXIF hints they carry and in size: the PNGs ran 2.8–8.6 KB, while the JPG ran 33.3 KB because JPEG spends bytes approximating the smooth content. If you want the smallest, cleanest PrintScreen capture, PNG is the better save target; if you want a smaller file, JPG is fine and still EXIF-free. Either way, no GPS, no camera, no device.

FAQ

Does Print Screen save metadata? No. Print Screen copies a raw bitmap to the clipboard; pasting into Paint and saving writes a fresh PNG or JPG, and in our test all three capture paths held 0 EXIF fields and 0 GPS.

Does Alt+PrintScreen keep metadata? No. Alt+PrintScreen only changes which pixels are copied (the active window); it still produces a fresh raster with no camera EXIF. Our Alt+PrintScreen PNG held 0 EXIF fields.

What about Win+Shift+S? Same verdict. Win+Shift+S saves a PNG directly (the Snip & Sketch path), and our sample held 0 EXIF fields and 0 GPS.

What if I PrintScreen a photo that has GPS? The GPS is gone. We built a JPEG with real GPS and four GPS fields, captured it the way PrintScreen does, and the result held 0 EXIF fields — piexif could not even read an EXIF block from it.

What metadata does a PrintScreen capture actually have? A pixel-density hint (pHYs at 96 DPI in our PNGs, JFIF 96 in our JPG) and, in real Snip & Sketch output, an sRGB color profile and a gamma tag. None of it is camera EXIF, and none of it is a location.

Is this true on other capture tools too? Yes, for the same reason: any screenshot is a pixel capture with no camera in the pipeline. The per-OS breakdown is on the do screenshots have exif data guide, and the Snipping-Tool-specific proof is in our Snipping Tool test.

Can I verify this on my own PrintScreen? Yes. Open any EXIF viewer, or parse the PNG for an eXIf chunk and the JPG for an APP1/Exif marker. If neither is present, the capture has no EXIF.