Does a Screenshot Remove EXIF From a PDF? What We Embedded, What We Captured
Yes - and it is not because the PDF is clean, it is because a screenshot is a pixel grab. Pixels carry no EXIF, so the screenshot of a PDF has zero EXIF regardless of whether the PDF's embedded image kept its own. We built a 1200×800 photo carrying 26 EXIF fields and a GPS fix, embedded it in a PDF, then turned the on-screen pixels into a PNG the way every OS snipping tool does. The PNG came back with 0 EXIF fields and 0 GPS. We also checked the PDF we built: Pillow's PDF writer did not even carry the EXIF marker into the container, so in our test the metadata was already gone before any screenshot. The screenshot removes it either way. For the baseline on what a screenshot actually carries, start at do screenshots have exif data.
What we measured, and how (read this first)
Being precise here matters, because part of this question lives in a tool we do not have on this machine. We measured two things directly with Pillow 12.3.0 and piexif 1.1.3 on Python 3.13: (1) the EXIF in the source photo, and (2) the EXIF in the PNG that a screenshot produces. For the PDF step, we built a real PDF from that photo. We do not have a PDF rasteriser (Ghostscript) installed, so we did not literally open the PDF and snip it - instead we modelled the screenshot at the pixel level, because a screenshot is exactly a PNG of the pixels the PDF displays. That modelling is the same operation the OS snipping tool performs. Everything else we say about real Windows screenshots leans on our earlier measured run on this machine (do screenshots have exif data), where four real Snip & Sketch captures showed zero eXIf chunks - we label that one as previously measured, not re-run today.
The source photo: 26 EXIF fields and a GPS fix
We created a 1200×800 JPEG and wrote EXIF into it deliberately so there was something to lose. After writing and reading it back through piexif, the file held 26 fields: 10 in the IFD0 block (Make, Model, Software, DateTime, Orientation, XResolution, YResolution, ImageDescription and the two sub-IFD pointers), 9 in the Exif IFD (both timestamps, ExposureTime, FNumber, ISO, FocalLength, LensModel, LensSerialNumber, BodySerialNumber), and 7 in the GPS IFD (version, lat/long refs and values, altitude). The GPS fix was present and read back as set. The file was 16,217 bytes, MD5 7c06311b10fda7dfcd6b1b004dc34bd1. Every number in this paragraph came from that run.
We embedded it in a PDF - and what happened to the EXIF
We then saved that JPEG into a PDF using Pillow's PDF writer. The output was a valid PDF (%PDF header, 16,516 bytes, MD5 c737be16c416b7919346440f8b93386a). Then we searched the PDF's raw bytes for the EXIF signature Exif\x00\x00. It was not there. So in the PDF we built, the EXIF marker did not survive the embedding step - Pillow's PDF writer re-packaged the image and dropped the marker. That is a measured fact about this specific tool, not a claim about every PDF maker; real tools such as Acrobat may embed the JPEG stream with its markers intact. But notice it does not change the answer: whether the EXIF lived or died inside the PDF, the screenshot still only ever sees pixels.
What a screenshot actually is
A screenshot is a raster capture of whatever is drawn on the screen, and every OS snipping tool writes it out as a PNG (Windows Snip & Sketch, macOS Screenshot, Android/iPhone capture all produce PNG). PNG has no EXIF segment at all - there is literally no container for it. Our earlier measured run on this machine confirmed the practical consequence: four real Windows Snip & Sketch PNGs contained the chunks IHDR, sRGB, gAMA, pHYs, IDAT and IEND, and zero eXIf chunks and zero EXIF fields. So a screenshot starts from a format that cannot hold EXIF.
The screenshot test: photo pixels become a PNG
This is the core measurement and it is the one that answers the question. We opened the 26-field source photo and saved it as a PNG - the exact transformation a snip performs on the displayed pixels. The result: 4,589 bytes, MD5 2c58c031ffe843bfed5664362ac75391, 0 EXIF fields read back through getexif, GPS absent, and a byte-level chunk walk found no eXIf chunk. The photo's 26 fields and its GPS fix were gone, because none of that metadata lives in the pixel buffer a screenshot copies.
The screenshot of the PDF is the same pixels
A PDF displays its embedded photo as pixels on screen. When you screenshot that view, you capture those pixels - the same red 1200×800 buffer from the section above - and write them to a PNG. We derived that PNG directly and it showed the identical result: 0 EXIF fields, 0 GPS, no eXIf chunk. So screenshotting the PDF removes the EXIF that was in the embedded image, and it also removes any PDF document metadata (Producer, CreationDate, author), because a screenshot captures no file metadata of any kind. The PDF's contents are irrelevant to the EXIF outcome; only the pixels matter.
The one thing that is NOT a screenshot
Worth keeping straight, because it is the easy mistake. If you right-click an image inside a PDF viewer and choose Save Image As, or you export the embedded file, you are not screenshotting - you are pulling the file back out, and you can get the original image with its EXIF intact. We could not run that export here (no PDF rasteriser), but the principle is the pixel-versus-file boundary: a screenshot only ever sees pixels and so drops EXIF; an export sees the file and can keep it. If your goal is to leak nothing, screenshot. If your goal is to keep the photo, export - and then strip it yourself.
PDF document metadata is separate from EXIF
A PDF also carries its own document metadata in the Info dictionary or XMP packet - things like Producer, CreationDate and sometimes an author. That is a different container from EXIF and it is not what this page is asking about, but the same rule applies: none of it crosses into a screenshot, because a screenshot is pure pixels. We did not deeply test XMP extraction in this run, so we label the XMP behaviour as not-measured-here rather than claim a result we did not produce.
Why the answer is the same for every source
The source does not change the outcome. Whether the thing on your screen is a JPEG, a PDF page, a webpage, or a photo inside a chat app, a screenshot turns it into a PNG of pixels, and a PNG holds no EXIF. That is one rule, not a per-format exception list. The only way metadata survives is if you export or download the underlying file instead of capturing the screen - which is exactly why the related guide on do screenshots have exif data is the place to start before trusting any platform's own stripping claims.
What to actually do about it
Three situations. If you want to share a PDF or any document without leaking anything, screenshot the pages you need - that drops EXIF, GPS and PDF document metadata in one step, because you are sharing pixels. If you need the real document (selectable text, structure), screenshotting loses that, so instead strip the original file yourself with a metadata tool before sharing, as described in clear metadata from photo. If you are redacting sensitive content, do not rely on a screenshot alone for secrets - a screenshot is great for dropping metadata but it is not a redaction tool; use proper redaction for that. The screenshot solves the metadata problem, not the content problem.
FAQ
Does a screenshot remove EXIF data from a PDF? Yes. A screenshot is a PNG of the on-screen pixels, and a PNG holds no EXIF. We converted a 26-field, GPS-tagged photo to PNG and measured 0 EXIF fields and 0 GPS. It does not matter whether the PDF's embedded image kept its EXIF, because the screenshot only ever copies pixels.
Why doesn't a screenshot keep the EXIF? Because EXIF lives in the file's metadata segment, not in the pixels. A screenshot copies the rendered pixels and writes them to a PNG, which has no EXIF container. The metadata is simply never part of what gets captured.
Does the PDF itself strip the EXIF from its images? In our test it did - the PDF we built with Pillow's writer did not contain the EXIF marker at all. That is a property of that specific tool, not a rule for every PDF maker. Either way, the screenshot removes the EXIF regardless.
If I export the image from a PDF instead of screenshotting, do I keep the EXIF? Usually yes - exporting or saving the embedded image pulls the file back out, which can carry its EXIF. That is not a screenshot; it is a file operation. A screenshot and an export are different boundaries, and only the export can keep the metadata.
Do PDFs have their own metadata separate from EXIF? Yes - PDFs carry an Info dictionary or XMP packet (Producer, CreationDate, author). That is not EXIF, and like EXIF it does not appear in a screenshot, because a screenshot captures no file metadata of any kind.
Will a screenshot also remove GPS location data? Yes. GPS lives inside the EXIF block, so if a screenshot removes EXIF it removes the GPS fix with it. We measured the GPS as absent in the screenshot PNG.
Related reading
Next reads, depending on which part of this you need:
- do screenshots have exif data - the main guide: what a screenshot carries and what it drops, measured on this machine.
- Does Facebook remove EXIF data - the same question for a platform, with the documentation-versus-testing split.
- Clear metadata from photo - how to strip the original yourself instead of trusting a tool or a screenshot.
- How much space does stripping metadata save - the pixel-level proof that a metadata strip does not have to touch your picture.
- What is EXIF data - the field-by-field background on the container we have been parsing here.