Do Screenshots Have Metadata? What Phones and Laptops Record

“Do screenshots have metadata” is a question people type at a very particular moment: just after sending one, and just before deciding whether that was a mistake. The answer they are hoping for is no. The answer they need is longer than that.

Screenshots do have metadata, but much less than a camera photo. Expect creation and modification timestamps, pixel dimensions, a colour profile, and often a software or device identifier. Expect no GPS coordinates, no shutter speed, no ISO, no lens data and no camera serial number, because none of those exist in a screen capture pipeline. What people usually mean by the question is “does a screenshot know where I was”, and to that one the answer really is no.

The half that gets missed is not in the file at all. A screenshot records your screen, which means it records the notification banner that slid in at the top, the Wi-Fi network name, the tab titles across your browser, the account initial in the corner, and the time on your phone down to the minute. No metadata remover touches any of it.

So the useful version of this article covers both: what gets written into the file, and what gets written into the pixels. Those are different problems with different fixes.

The short answer

Screenshots do have metadata, but much less than a camera photo. Expect creation and modification timestamps, pixel dimensions, a colour profile, and often a software or device identifier. Expect no GPS coordinates, no shutter speed, no ISO, no lens data, no camera serial number and no MakerNotes, because none of those exist in a screen capture pipeline.

The format matters. iOS and Pixel screenshots are PNG by default, and PNG has no native EXIF block. Its text lives in tEXt, iTXt and zTXt chunks instead, which is why a viewer built only for JPEG EXIF will show you an empty page and you will wrongly conclude the file is clean.

Your bigger exposure is visual. Banners, tab titles, account names, timestamps, wallpaper and URL bars all sit in the image itself, and no metadata remover touches them. Look at the picture before you look at the tags.

What a screenshot can and cannot contain

Think about what a screenshot actually is. The compositor already has the finished frame in memory, so the capture is a copy of a buffer plus a file header. There is no sensor, no lens, no exposure, no autofocus and no location request anywhere in that chain. Every field that would normally be filled by a camera has nothing to fill it with.

What is left is genuinely small:

• Pixel dimensions and bit depth (always present, in the PNG IHDR or the JPEG frame header).
• A colour profile, commonly sRGB or Display P3 on modern Apple hardware.
• A physical resolution hint, in PNG’s pHYs chunk. A value of 2835 pixels per metre is 72 DPI; 11811 is 300 DPI.
• A creation or modification time, in a tIME chunk, a text chunk, or an EXIF field if the platform writes one.
• Sometimes a software or model string.

That is close to the whole list. Compare it against the GPS tags a camera photo carries and the gap is obvious.

Why PNG metadata hides from some viewers

PNG stores everything in chunks: a four-byte length, a four-byte type, the data, and a CRC. Chunks whose type starts with a lowercase letter are ancillary, meaning a decoder is allowed to ignore them. Text lives in three of them:

• tEXt holds an uncompressed Latin-1 keyword and value.
• zTXt holds the same thing zlib-compressed, so it is invisible to anything grepping the raw bytes.
• iTXt holds UTF-8 text with a language tag, optionally compressed, and it is where XMP goes under the keyword XML:com.adobe.xmp.

The registered keywords for those chunks include Title, Author, Description, Copyright, Creation Time, Software, Source and Comment. A PNG can also carry a real EXIF payload in an eXIf chunk, which was registered in 2017 and folded into the PNG specification’s third edition, but plenty of software still neither writes nor reads it.

This is exactly why two metadata viewers can disagree about the same screenshot. One parses JPEG APP1 segments and nothing else. Another walks the PNG chunk list properly. If a tool tells you a PNG has no metadata, that might be a fact about the file, and it might be a fact about the tool. When it matters, check with a second one.

Platform by platform

Behaviour differs by operating system, and by manufacturer within Android. Treat the table below as the general shape rather than a permanent truth, because vendors change capture pipelines in point releases without mentioning it in any changelog. Test your own device.

iOS

iPhone screenshots have been PNG for years, and the resolution is a fingerprint. A 1179 by 2556 file narrows the device to a specific class of iPhone immediately. The raw file itself is sparse, but the Photos library holds its own record of when the capture happened, and sharing from Photos rather than from Files can add fields the untouched file did not have.

Apple has changed image formats before and will again, so if you care, look at the extension on your own most recent screenshot rather than trusting anyone’s summary from last year.

Android

Android has no single answer because the screenshot handler belongs to the manufacturer. Pixel writes PNG and, since Android 12, puts the capturing app into the filename: Screenshot_20260314-091207_Gmail.png. Read that again. The filename gives you the date, the time to the second, and the app the user was in. Samsung lets you pick PNG or JPG under Settings, Advanced features, Screenshots and screen recorder, and choosing JPG gets you a real EXIF block where PNG had none.

Filenames survive email and messaging attachments perfectly well. If you are sending a screenshot to someone who should not know what you were doing at 09:12, rename it.

macOS

The screencapture service writes PNG, embeds the display’s colour profile (Display P3 on most current Macs), and names files Screenshot 2026-03-14 at 09.12.07.png by default. Three preferences are worth knowing:

• defaults write com.apple.screencapture type jpg changes the format.
• defaults write com.apple.screencapture include-date -bool false drops the timestamp from the filename.
• defaults write com.apple.screencapture location ~/Pictures/Screenshots moves the destination.

Run killall SystemUIServer afterwards for the change to take effect.

macOS also tags screenshots with Spotlight attributes including kMDItemIsScreenCapture and kMDItemScreenCaptureType. Those live in extended attributes on the filesystem, not inside the image, so they vanish the moment the file is copied to a non-Apple volume or uploaded anywhere. Useful to know in both directions: they are there locally, and they do not travel.

Windows

Print Screen on its own puts a bitmap on the clipboard and creates no file at all, which is why pasted screenshots have essentially nothing attached. Win+PrtScn saves a PNG into Pictures\Screenshots. The Snipping Tool lets you choose PNG, JPG or GIF and writes correspondingly more or less metadata. Windows Explorer’s Date created and Date modified columns are filesystem properties and have nothing to do with the file’s contents.

Two timestamps that disagree, and which one to believe

This trips people up constantly. A file has filesystem timestamps, and an image may have embedded ones, and they answer different questions.

Filesystem timestamps describe the file’s life on this volume. Copy a screenshot from your phone to a laptop and Windows sets Date created to now while leaving Date modified at the original value, producing the deeply confusing situation where a file appears to have been modified before it was created. On macOS, cp resets the modification time unless you pass -p. Download something from Google Drive, Dropbox or WeTransfer and every timestamp becomes the moment of download.

Embedded timestamps describe the image. A PNG tIME chunk, a Creation Time text chunk, or an EXIF DateTimeOriginal in a JPEG screenshot all stay put through copying, because they are part of the data rather than part of the directory entry.

For screenshots specifically, the default filename is often the most reliable capture record you have, precisely because iOS, Android and macOS all bake the timestamp into it and nothing later rewrites it. That feels backwards. It is also true, and it is why renaming a screenshot before you send it is a genuinely effective privacy step for about two seconds of effort.

The catch is the flip side. If you are trying to establish when something happened from a screenshot someone sent you, none of this is evidence. Filenames are trivially editable, filesystem dates get rewritten by every transfer, and the visible clock in the status bar is just pixels. Screenshots are weak proof of timing, and I would not build an argument on one.

What screenshots really leak

Here is where the actual risk sits, and it has nothing to do with EXIF.

Everything visible in the frame is in the file. In practice that means:

1. Notification banners that arrived mid-capture, including message previews from other conversations.
2. The status bar: carrier name, signal, battery percentage, alarm icon, and the clock.
3. Browser tab titles across the top, which quietly describe everything else you had open.
4. The URL bar, which can contain session tokens, unsubscribe identifiers, email addresses in query strings, or an internal hostname.
5. Account names and profile initials in application corners.
6. The Dock, taskbar and desktop wallpaper, which is frequently a photo of someone’s family.
7. Sidebar contents in chat apps: channel names, client names, unread counts.
8. Autocomplete and autofill dropdowns caught mid-render.
9. In a video call screenshot, every other participant’s name.

I would rank a careless screenshot as more revealing than a geotagged photo in most everyday situations, which is close to the opposite of how the two are usually discussed. A geotag tells someone one thing about you. A full-screen capture of a working laptop tells them twenty.

The fix is prosaic. Crop tightly to the thing you actually want to show, and cover the rest before sending. Censor Image draws solid blocks, and solid is the word to hold onto: a black rectangle is a better redaction than a blur.

That is not a stylistic preference. Blurring and light pixelation are reversible in some situations, particularly over short strings of text in a predictable monospaced font, where an attacker can render every candidate string, apply the same blur, and match. If you use Pixelate Image, use a block size large enough that the region becomes a few flat squares rather than a recognisable smear. For faces in a screenshot, Blur Face is the quicker route.

The cropping problem nobody expected

For years the standard advice was that cropping a screenshot removes the cropped part, because obviously it does. In 2023 two separate bugs showed that “obviously” was doing a lot of work.

The first was CVE-2023-21036, nicknamed aCropalypse, in the Markup tool on Google Pixel phones. When you cropped a screenshot and saved it, the tool opened the existing file for writing without truncating it. The new, shorter image was written over the beginning, and the tail of the original file stayed exactly where it was. Given the right tooling, a lot of the cropped-out region could be reconstructed. Google patched it in the March 2023 Pixel security update.

Days later came CVE-2023-28303, the same class of mistake in the Windows 11 Snipping Tool and the Windows 10 Snip and Sketch app. Microsoft fixed it through app updates shortly after.

Both are patched, so this is not a live warning about your current phone. It is a reason to think about files you already produced and already shared, which is the honest framing: cropped screenshots you posted publicly in or before early 2023 from an affected Pixel or Windows machine are the ones worth a second look, if any of them were cropped to hide something.

There is a milder version of this that is not a bug at all. Photo libraries crop non-destructively on purpose. Apple Photos and Google Photos both keep the untouched original alongside an adjustment record so you can hit Revert. Exporting an “unmodified original”, restoring from a backup, or sharing through a path that hands over the library asset rather than the rendered edit can all surface the uncropped image. That is a feature working as designed, and it will still surprise you at the wrong moment.

If you want a crop that is definitively a crop, export the cropped version as a new file and check it. Opening the result in ToolFiddle’s EXIF Viewer shows you the file’s real dimensions and whatever tags came along with it, all processed inside your browser so the screenshot you are worried about never leaves your machine. Thirty seconds, and you know rather than assume.

A worked example

Say Dana screenshots a hotel booking on a Pixel 8 to send to a friend. The file lands in her gallery as Screenshot_20260314-091207_Gmail.png, 1080 by 2400, 412 KB.

Run it through a viewer and the metadata is thin: IHDR giving 1080 by 2400 at 8 bits per channel, an sRGB chunk, a pHYs chunk, IDAT image data, IEND. No GPS. No camera fields. No serial number. On the metadata axis the file is close to inert.

Now read the picture. The filename says Gmail and pins the capture to 09:12:07 on 14 March 2026. The status bar shows her carrier and a Wi-Fi icon. A banner across the top previews a message from a name she would rather not share. The booking shows a hotel, dates, a confirmation code, and the last four digits of a card. Her friend needs the hotel and the dates and nothing else.

Two minutes of work: crop to the reservation block, cover the confirmation code and the card digits with solid rectangles, rename the file to booking.png, and convert it to JPEG with PNG to JPG, which incidentally drops the PNG text chunks and takes the file from 412 KB to roughly 90 KB at quality 80. The metadata was never the problem. The banner was.

How to audit a screenshot before you send it

1. Look at the filename. Does it name an app, a date, a time, a project or a client? Rename it if so.
2. Look at the top strip: clock, carrier, battery, Wi-Fi name, notification banners.
3. Look at the edges: tab bars, sidebars, the Dock, the taskbar, open window titles behind the active one.
4. Look for identifiers in the content itself: email addresses, order numbers, booking references, partial card numbers, internal URLs, ticket IDs.
5. Crop hard, then cover what remains with solid blocks rather than blurs.
6. Open the finished file in EXIF Viewer and confirm what the exported version actually carries. If anything looks unwanted, run it through Metadata Remover and check again.

Step six is the one people skip, and it is the only one that turns an assumption into a fact.

The recurring mistakes

Treating “screenshot” as a privacy method. Screenshotting a geotagged photo does drop the GPS, and it also gives you a downscaled, re-encoded copy at whatever resolution your screen happens to be. As a way to remove metadata it works. As a habit it quietly destroys your image quality, and there is no reason to accept that when stripping the file directly costs the same effort.

Assuming PNG means no metadata. PNG carries plenty, just in chunks rather than an EXIF block, and zTXt is compressed so it will not turn up if you go looking through the raw bytes with a text search.

Forgetting that platforms handle screenshots the same way they handle photos. Upload a PNG screenshot to Instagram or X and it gets re-encoded to JPEG and the chunks go with it, which is fine for privacy and bad for the crispness of screenshotted text. If you want a screenshot to stay sharp, the rundown of what each platform strips and re-encodes is worth reading before you pick where to post it.

Redacting inside the app you screenshotted. Highlighter tools in markup layers are frequently semi-transparent by design. Black pen is opaque; yellow highlighter over black text is not, and neither is a low-opacity brush. Zoom in on your own redaction before you send it.

Sending the screenshot as a document. Chat apps that compress images will usually re-encode a screenshot and drop its text chunks. Choosing “send as file” specifically bypasses that. If you picked that option to preserve quality, you also preserved everything else.

Frequently asked questions

Do screenshots have EXIF data?

Sometimes, but very little. A screenshot has no camera, no lens and no GPS receiver behind it, so there is no exposure or location data to record. What you may find is a creation timestamp, pixel dimensions, a colour profile and occasionally a software or device name. PNG screenshots often carry no EXIF block at all, storing any text in PNG chunks instead, which is why some viewers report nothing.

Does a screenshot show location?

Not through metadata. No mainstream operating system writes GPS coordinates into a screenshot, because the screen capture pipeline never asks for a location fix. Location can still leak visually, through a map on screen, a weather widget naming your town, a delivery address in an email, a Wi-Fi network name in the status bar, or a photo of a recognisable place in your wallpaper.

Can someone tell what device took a screenshot?

Often roughly, yes, and usually from the picture rather than the metadata. Pixel dimensions narrow the device family, since 1179 by 2556 points at a specific class of iPhone. The status bar layout, notch or island shape, system font, icon set and default filename pattern all indicate the platform. Some Android manufacturers also write a software or model tag into the file when saving as JPEG.

Do screenshots have a timestamp?

Usually two, and they can disagree. The file has filesystem timestamps that change when you copy, sync or email it, and the image may carry an embedded creation time in a PNG text chunk or an EXIF field that does not change. On iOS, Android and macOS the capture time is also baked into the default filename, which is often the most reliable record until someone renames the file.

Is a screenshot safer to share than the original photo?

For metadata, yes. Screenshotting a geotagged photo produces a new file with no GPS, no camera serial number and no lens data. You pay for it in quality, since you get a downscaled, re-encoded copy of what your screen displayed rather than the original pixels. A metadata remover keeps the quality and removes the data, which is the better trade in nearly every case.

Does cropping a screenshot remove the part I cropped out?

It should, and normally it does. Two well-documented 2023 bugs proved it is not guaranteed: aCropalypse in the Pixel Markup tool and a matching flaw in the Windows Snipping Tool both left original pixel data recoverable after a crop. Both were patched that year. Phone photo libraries also keep the uncropped original by design so you can revert an edit, so check what you are actually exporting.

What to actually watch for

Screenshots are the least revealing image files most people produce, measured in tags. No coordinates, no camera, no serial number, barely a timestamp in some cases. If your only worry is metadata, a screenshot is close to a clean slate.

The reason to slow down anyway is that the format shifts the exposure from the invisible half of a file to the visible half, and the visible half is the one you can fix with your eyes. Crop before you send. Rename before you send. Cover things with solid blocks rather than blurs. Then, if the screenshot is going anywhere permanent, open the finished file and confirm what actually came out the other side rather than trusting what you meant to happen.