Do Mac Screenshots Have EXIF Data? No — but macOS Does Stamp the DPI

No — a Mac screenshot does not carry GPS, no camera make/model, and no EXIF block. macOS saves the shot as a PNG (Apple documents this), keeps the capture date and time in the file name (Screen Shot 2024-01-20 at 10.30.15 AM.png), and by default also writes the screen’s DPI into the PNG. None of that is camera EXIF. The full picture is on our main guide, do screenshots have exif data. Honesty note: this article is compiled from Apple’s screenshot support page and the macOS screencapture manual, plus a live check of the standard metadata viewers. We did not run a Mac screenshot test in this session, so treat the field-level claims as documented behavior, not a byte read we performed.

The short answer, spelled out

On a PC a screenshot is a fresh pixel capture where do screenshots have exif data is answered with a flat ‘no’ — the OS writes a clean container from scratch. macOS behaves the same way: when you press Shift-Command-3, Shift-Command-4, or open the Screenshot app (Shift-Command-5), the system grabs the screen as a bitmap and exports a PNG. There is no camera, no lens, and no GPS fix behind it, so there is nothing to stamp into an EXIF block. The one quirk that separates a Mac from a Windows or Android machine is that macOS, by default, also writes the screen’s DPI into the PNG — more on that below. The one exception in this whole series is the iPhone (see our iPhone screenshots + EXIF write-up), because iOS routes the capture through its camera-image pipeline and does stamp a small block; Android, like the Mac, keeps the time in the filename instead (our Android screenshots + EXIF piece).

What is actually inside a Mac screenshot

Based on Apple’s documented screenshot behavior and the screencapture manual, here is the field-level picture. The leftmost column is the metadata; the middle is whether it shows up in a Mac screenshot; the right is how we know.

MetadataIn a Mac screenshot?How we know
Capture date & timeNo — lives in the filename (Screen Shot YYYY-MM-DD at HH.MM.SS AM.png), not EXIFApple Support “Take a screenshot on your Mac”: the filename includes date and time
GPS / locationNoNo camera in the pipeline; a screenshot captures pixels, not a fix
Camera make / model / lensNoNo camera in the pipeline
Screen DPI (PNG pHYs)Yes — by defaultThe screencapture manual documents a -r flag “Do not add screen dpi meta data to captured file,” which means the default capture adds it
Color profile (sRGB / gAMA)Possibly — via PNG chunks, not EXIFPNG spec; macOS color management
Pixel dimensionsYesAlways present
EXIF block (DateTimeOriginal etc.)NoPNG has no camera-EXIF structure; macOS does not write an eXIf chunk for screenshots

Why the date and time live in the filename, not EXIF

Apple documents that a screenshot file is named starting with “Screenshot” (or “Screen Recording”) and includes the date and time — the real English pattern is Screen Shot 2024-01-20 at 10.30.15 AM.png. That timestamp is text in the file name, not a tag inside the image. A camera photo stores the moment it was taken as DateTimeOriginal inside EXIF; a screenshot has no such field, so the only machine-readable “when” is the name plus the file’s own created/modified timestamps. This is the same pattern as Android’s Screenshot_YYYYMMDD-HHMMSS.png name (our Android piece covers it) — different format, same idea: the time is outside EXIF.

The one metadata macOS does add: the screen DPI

This is the Mac-specific detail most “do screenshots have EXIF” answers miss. The macOS screencapture manual lists a -r flag described literally as “Do not add screen dpi meta data to captured file.” The existence of a flag to remove DPI metadata means the default capture adds it. In PNG that DPI is stored as a pHYs chunk — exactly the 119.99 DPI value our main guide measured when it read a real screenshot chunk by chunk. So a Mac screenshot, inspected at the byte level, shows a DPI chunk but zero EXIF and zero GPS. The takeaway: macOS writes one piece of metadata a Windows or Android shot does not, and it is the screen’s resolution, not anything about you. Our do screenshots have exif data guide shows the actual chunk-by-chunk read that proves a screenshot container holds DPI/sRGB/gAMA but no EXIF.

The location question (and what is NOT in the file)

The reassuring part: a Mac screenshot holds no GPS, so dropping it into geotag.world (live when we checked on 2026-10-25) returns no coordinates. No camera make, no lens, no shutter speed. If you screenshot a map, a chat, or a photo, the original photo’s GPS is gone; you captured pixels, not a file. We also attempted to load exifdata.org and exifreader.org on 2026-10-25 and both returned HTTP 502 (bad gateway), so we are not quoting their pages — we name them only as the standard EXIF viewers you can drag a screenshot into yourself once they are back up.

How we know this (and what we could not check)

We are explicit about sourcing because this is a documented-behavior article, not a Mac test. Verified this session: Apple’s “Take a screenshot on your Mac” support page states screenshots are saved as .png and the filename includes the date and time. The macOS screencapture manual documents that -t format defaults to png (other options include pdf, jpg, tiff, gif, bmp), that -r suppresses screen DPI metadata, and that the default save location is the Desktop (changeable via defaults write com.apple.screencapture location). GeoTag.World returned HTTP 200 on 2026-10-25. Not checked this session: we did not run a Mac in this environment, so there is no byte read of a real Mac screenshot here; the field-level claims are Apple’s documented behavior. exifdata.org and exifreader.org both returned HTTP 502 on 2026-10-25, so we are not quoting them.

How to check your own Mac screenshot

Three ways, none of which upload your file. Open the file in a metadata viewer, or run ExifTool locally: exiftool "Screen Shot"*.png lists every tag — you will see no EXIF block and no GPS, and the capture time will be in the file name, not the tags (you may see a PNG pHYs DPI entry, which is the macOS default). Or drag the PNG into geotag.world (live on 2026-10-25) to confirm there is no GPS; exifdata.org and exifreader.org are the other standard viewers, though both returned HTTP 502 when we tried them on 2026-10-25. Because there is no EXIF to read, the most useful metadata you have is the filename timestamp.

If you want that metadata gone

There is essentially nothing sensitive to remove from a Mac screenshot — no GPS, no make/model. The one thing macOS does add is the screen DPI, and you can stop it at capture time with screencapture -r, or strip it afterwards with any metadata remover that rewrites the PNG without extra chunks. Our do screenshots have exif data guide covers the general mechanism, and clear-metadata-from-photo walks the one-click path. Because the only time clue is the filename, you may also want to rename the file if hiding when it was taken matters to you.

FAQ

Do Mac screenshots have EXIF data? No. They carry no GPS, no camera make/model, and no EXIF block; macOS exports a clean PNG from a screen capture with no camera pipeline.

Do Mac screenshots have GPS or location data? No. A screenshot captures pixels, not a GPS fix, so there is no location in the file; GeoTag.World confirms there is nothing to read.

Where does a Mac store the screenshot time if not in EXIF? In the filename — Screen Shot 2024-01-20 at 10.30.15 AM.png — and in the file’s own timestamps, per Apple’s screenshot support page.

Do Mac screenshots have any metadata at all? Yes, one piece by default: the screen’s DPI, written as a PNG pHYs chunk. The screencapture -r flag exists specifically to suppress it.

Why does a Mac add DPI but not EXIF? DPI describes the display the pixels came from and is a PNG-native chunk; EXIF is a camera-image structure macOS does not write for a screen capture.

Was this tested on a Mac? No. This is documented behavior compiled from Apple’s screenshot support page and the macOS screencapture manual, plus a live check of GeoTag.World; we did not run a Mac screenshot test in this session.