What metadata does a screenshot actually contain?

Published 19 August 2026

A screenshot feels safe to share precisely because it feels like it skips the usual risks — no camera, no lens, no GPS chip involved in making it. That instinct is mostly right and occasionally wrong in a way worth knowing about: what a screenshot carries depends entirely on the tool that captured it, not on the fact that it's a screenshot.

What a screenshot doesn't carry

No camera hardware means no BodySerialNumber, no LensSerialNumber, no exposure settings — the entire category of EXIF fields that identify a specific physical device simply has nothing to populate it, because there's no device in the capture path beyond the computer or phone taking the screenshot. GPS is the same story in the common case: a screenshot tool has no reason to query location services, so the GPS sub-IFD that a phone photo carries is typically absent entirely.

What most screenshot tools write anyway

A capture timestamp is close to universal — the file's own filesystem metadata records when it was created regardless of what's embedded inside it, and many capture tools additionally embed the time inside the image file itself. On macOS specifically, the built-in capture shortcuts write a PNG with a full tEXt chunk under the key XML:com.adobe.xmp, holding an XMP packet timestamped to the second — readable in a plain text editor, since PNG's ancillary chunks are uncompressed text rather than binary EXIF tags. Most Linux screenshot tools follow a similar pattern: a timestamp, and often the name of the application that generated the file.

The part that actually matters: what you captured, not how

The realistic privacy risk in a screenshot was never really about embedded metadata to begin with — it's about content. A screenshot of a chat, an email, a banking app or a medical portal shows exactly what was on screen at that moment, unredacted, in the pixels themselves. No metadata tool touches that, including this one: stripping a screenshot's timestamp and source-application field doesn't remove anything visible in the image, because that information was never pixel data to begin with. If a screenshot shows something you don't want seen, cropping or blurring the visible content is the only fix — the same limitation covered on the quality page applies here in reverse: metadata and content are separate axes, and a metadata tool only ever touches one of them.

Edited screenshots carry more than raw ones

A screenshot opened in Photoshop or a similar editor for annotation — arrows, a highlight box, blurred-out text — picks up an additional chunk most people don't expect: caNv, Photoshop's canvas geometry field, which records the crop applied to the image. If the original uncropped capture included something the crop was meant to hide, that geometry data is a record that a wider capture existed, sitting in the file even after the visible crop looks clean. This is the same risk a cropped camera photo carries, just arriving by a different path — through an editor rather than through the capturing device.

Check your own

The only way to know what a specific screenshot carries is to look — assumptions about "screenshots are safe" or "screenshots are risky" are both wrong often enough to be worth checking directly. Drop one into the PNG tool and every chunk it contains is listed before anything is removed, the same way it would be for any other PNG.