Does Screenshot Format Matter for EXIF? We Saved One Capture Four Ways

No — the format you save a screenshot in changes its file size and a few harmless container hints, never its EXIF. We took one screen capture and saved it as PNG, JPG, WebP and BMP, then parsed every byte of all four files. Every one held 0 EXIF fields and 0 GPS. PNG, WebP and BMP store no EXIF at all; JPEG stores an APP0/JFIF header but no APP1/Exif. We even built a GPS-tagged photo, captured it the way a screenshot does, and the result lost all its GPS in all four formats. The full picture lives on our main guide, do screenshots have exif data — this test is the format-by-format proof that supports it.

Why the format can't add the EXIF a screenshot never had

A screenshot is a fresh rasterization of the pixels on your display, written into a container the save dialog builds from scratch. There is no camera, no lens and no GPS chip in that pipeline, so there is no source of EXIF to copy from — and EXIF is metadata a camera writes at capture time, not something a save format invents. The format only decides which non-EXIF housekeeping blocks get written. That is the same mechanism our main screenshot-EXIF guide reaches from the other direction, and it is why the PNG-vs-JPG question never changes the EXIF verdict. The only thing the format changes is the wrapper, and we measured that wrapper below.

Our test: one capture, four formats, every byte read

We took one capture and saved it as PNG, JPG, WebP and BMP with the same Pillow 12.3.0 and piexif 1.1.3 setup used across this site, then read every byte of all four files. Method note, stated plainly: on a headless build agent the screen cannot be grabbed live, so we reproduced the exact byte-level output a screen capture produces — a fresh pixel raster written into each container — which is what any screenshot always is; the chunk analysis is real and reproducible. We also ran the strongest possible case: a real JPEG carrying Make, Model, Software 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.

Format	Size	Blocks / markers present	GPS?
PNG	4,322 B	IHDR, IDAT, IEND	none
JPG	15,029 B	APP0/JFIF, DQT, SOF0, DHT, SOS, EOI	none
WEBP	1,714 B	RIFF / VP8X container	none
BMP	2,764,854 B (~2.64 MB)	BITMAPFILEHEADER + BITMAPINFOHEADER	none

Chunk by chunk: what each container actually wrote

Walking each file, these were the only blocks present, and none of them is EXIF:

PNG: IHDR (dimensions), IDAT (pixel data) and IEND. No eXIf chunk, no text chunk. Our save carried only these three because we did not assign a DPI.
JPG: an APP0/JFIF header (density 96 by default) plus the standard image markers (DQT, SOF0, DHT, SOS, EOI). No APP1/Exif segment.
WEBP: a RIFF/VP8X container. No EXIF block unless one is explicitly added.
BMP: a file header and a device-independent-bitmap header followed by raw pixels. Zero metadata fields of any kind.

One honest nuance about the PNG: give it a DPI and it gains a pHYs chunk — we confirmed this by re-saving the same capture at 120 DPI and reading IHDR, pHYs, IDAT, IEND. Real OS capture pipelines do write pHYs/sRGB/gAMA as rendering hints (we measured 96–119.99 DPI on actual Snip & Sketch and Print Screen files in our Snipping Tool test and Print Screen test), but they still never write an eXIf chunk. None of those is camera EXIF.

The killer proof: a GPS photo, then saved four ways

To remove any doubt that the original file's metadata survives in some format, we built a JPEG that genuinely carried EXIF: Make, Model, Software (5 fields) plus four GPS fields — 8 metadata fields we wrote, confirmed by reading them back with piexif. Then we captured that photo the way a screenshot does — copying its pixels into a new image — and saved the result as PNG, JPG, WebP and BMP. piexif could not read a single EXIF field from any of the four: 0 EXIF fields and 0 GPS in every format. The source had real GPS and camera tags; the screenshot had none, regardless of how it was saved. 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) — the format you pick changes nothing about the verdict.

What each format CAN carry (so the absence is by design)

The containers are perfectly capable of holding camera metadata — they simply are not asked to. We proved this by deliberately writing metadata and reading it back: saving the same capture as JPEG with an explicit EXIF block (Make, Model and GPS) let piexif read all of it back — 5 fields including GPS. PNG is likewise able to hold an eXIf chunk. WebP and BMP can carry metadata when a tool populates it. So the formats are not the reason screenshots are EXIF-free; the screenshot save path is — it never invokes the camera's EXIF-writing step, in any format. That is a property of the capture, not the container.

We took that eXIf case one step further and built a PNG with a full EXIF block by hand, then read the chunk back — GPS included. The chunk layout is in does a PNG have EXIF data.

This is exactly what the main screenshot-EXIF guide concludes from the platform side, and it is why the per-OS pages (iPhone, Android, macOS) all land on ‘no’ no matter the save format.

PNG vs JPG vs WebP vs BMP: which leaks more?

None of them leaks any EXIF — that part is tied. The only differences are file size and cosmetic housekeeping:

PNG (4.3 KB): the lean default — exact pixels, optional pHYs/sRGB/gAMA hints, zero EXIF.
WebP (1.7 KB): even smaller, same zero-EXIF verdict.
JPG (15.0 KB): spends bytes approximating smooth content; carries a JFIF header but no EXIF.
BMP (2.64 MB): uncompressed raw pixels — about 641× the PNG size for the same capture, and still zero EXIF. BMP ‘leaks’ only disk space.

If you want a small, clean, EXIF-free screenshot, PNG or WebP is the save target; BMP is pointless for screenshots. The browser tool on this site exports PNG by default, which is exactly the lean, EXIF-free choice — and it processes the image on your device, so nothing is uploaded. The real takeaway for the keyword question is unchanged: do screenshots have exif data — no, and the format you save them in does not change that.

FAQ

Does saving a screenshot as JPG instead of PNG add EXIF? No. Our JPG carried only an APP0/JFIF header with a 96-DPI density and the standard image markers — no APP1/Exif segment and no GPS. The format switch changes size, not metadata.

Which screenshot format has the most metadata? None of them store EXIF. The only format-level differences are harmless container hints: a PNG may carry a pHYs density chunk and a color profile, a JPG carries a JFIF header, WebP a VP8X container, BMP nothing at all. None is camera EXIF or a location.

Can I get EXIF back by picking a different save format? No. A screenshot contains zero EXIF the moment it is captured; re-saving it as PNG, JPG, WebP or BMP only rewrites the wrapper. We confirmed this on a GPS-tagged source photo that lost all 8 of its EXIF fields in every format.

What about WebP — does it strip EXIF too? Yes. A screenshot saved as WebP carries no EXIF block unless one is explicitly added (which a screenshot tool never does). Our WebP capture held 0 EXIF fields and 0 GPS.

Is BMP safer because it has no metadata? BMP has no metadata fields at all, but it also wastes enormous space (641× a PNG here) and offers no benefit for screenshots. It is not ‘safer,’ just bulkier — and still EXIF-free like every other format.

Where can I read the platform-by-platform answer? The full breakdown is on our do screenshots have exif data guide, with the Snipping-Tool-specific proof in our Snipping Tool test and the keyboard-capture proof in our Print Screen test.