Do screenshots have metadata? Less than photos — but they leak in other ways
Taking a screenshot of a photo is common privacy advice. The logic sounds right: the camera wrote the EXIF, and a screenshot is a new image made by the operating system, so the EXIF shouldn't come along.
That part is mostly true. The trouble is that it leads people to treat screenshots as clean, and they often aren't. The leaks just come from different places.
What's actually in a screenshot file
Check one yourself:
exiftool -a -G1 Screenshot.png
Or drop it into the image metadata viewer.
A typical phone or desktop screenshot has:
- No GPS. The OS isn't using the camera, so there's no location fix to record. This is the part the advice gets right.
- A small metadata block anyway. Often dimensions, a color profile, sometimes a creation timestamp or a field labeling it a screenshot. It depends on the OS and version, so check rather than assume.
- A color profile that points to a platform. An embedded Display P3 profile, for example, is typical of Apple hardware.
So on metadata alone, a screenshot does give away much less than a camera photo. The other leaks are below.
Leak 1: the filename
Default screenshot names are timestamps:
Screenshot 2026-09-22 at 10.14.03.png
Screenshot_20260922-101403.png
Upload that file somewhere that keeps the original name — email, Discord, Slack, many file hosts, a lot of CMS media libraries — and you've published the exact second you took it. Metadata strippers don't rename files, because the name isn't inside the file.
Our safe file renamer handles this separately, or just rename it before sharing.
Leak 2: the resolution identifies the device
A photo gets resized, cropped, and recompressed. A screenshot is exactly the size of the screen that took it. Screen resolutions map closely to device models, so a 1179 × 2556 image narrows it down to a handful of recent iPhones. Desktop screenshots show your monitor resolution and scaling factor.
That's rarely a problem by itself. But if you're trying to keep two accounts separate, "same unusual resolution, same color profile" is exactly how they get linked.
Leak 3: everything the screen was showing
This is where most real screenshot leaks come from, and no metadata tool can fix it:
- The status bar — the time, your carrier, battery level, and sometimes a notification preview with someone's name.
- Browser chrome — other tab titles, bookmarks, extension icons, a logged-in avatar, the full URL including tracking parameters or a document ID.
- Chat screenshots — contact names, profile photos, and the "last seen" line above the message you meant to share.
- Desktop screenshots — file names on the desktop, the taskbar, the Wi-Fi network name.
Crop tightly, then look at what's left at full zoom before you post it.
Leak 4: the cropping bug that kept what you cut out
This one is real, and it's worth knowing about because it breaks the most basic assumption: that cropping removes pixels.
In 2023, security researchers disclosed a bug nicknamed aCropalypse in the Markup editor on Google Pixel phones (CVE-2023-21036). When you cropped or redacted a screenshot and saved it over the original, the tool wrote the new, smaller image at the start of the file but didn't truncate the file. The leftover bytes of the original, uncropped image stayed at the end. With the right tool, much of the part you cropped out could be recovered.
Shortly after, a closely related issue was found in the Windows 11 Snipping Tool and Windows 10 Snip & Sketch (CVE-2023-28303). Both were patched in 2023. But files edited on unpatched devices before then still carry the hidden data, and some of them are still sitting on image hosts and in chat logs.
The general lesson is bigger than one bug: editing a file in place doesn't guarantee the old content is gone. Embedded thumbnails that weren't updated after a crop are the same kind of failure, and so are PDF "redactions" that just draw a black box over text that's still there.
What actually makes a screenshot clean
Re-encode it from pixels. Draw the image onto a canvas and export a new file. The decoder only reads the visible image into memory, so trailing bytes, stale thumbnails, text chunks, and color-profile quirks don't make it into the output:
const canvas = document.createElement("canvas");
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
canvas.getContext("2d").drawImage(img, 0, 0);
canvas.toBlob(blob => { /* only the pixels you can see */ }, "image/png");
That's what the metadata cleaner does, and it runs in your browser, so the screenshot never gets uploaded. It also means an aCropalypse-style file comes out containing only the cropped version, because the leftover data was never part of the decoded image.
A quick way to see whether a file has trailing data: compare the file size to what it should be. A tightly cropped 400 × 300 PNG that weighs several megabytes deserves a closer look.
A checklist before you share one
- Crop to only what's needed, including the status bar.
- Check the edges at full zoom for notifications, tabs, and names.
- Blur properly. A solid box is safe; a light blur or pixelation over text can sometimes be reversed.
- Re-encode rather than trusting an in-place edit.
- Rename the file so the timestamp doesn't go with it.
The short version
Screenshots usually have no GPS, so the common advice isn't wrong. But the filename records when you took it, the resolution points to your device, the screen content is often more revealing than any EXIF field, and in-place editing has had real bugs that kept cropped pixels in the file. Crop, check, re-encode, rename.
Related: which platforms strip EXIF, and why iPhone photos keep location with GPS off.