How to Tell If a Screenshot Is Real or Edited

A screenshot can look perfectly convincing and still be completely fabricated, because a screenshot is not a photograph of the real world. It is a render of pixels that someone chose to display, crop, edit, or generate, and then saved as an image file. That means visual inspection alone is rarely enough. What you can do reliably is document the technical fingerprint the file carries, and compare it against what a genuine screenshot from a given device and operating system would normally produce. Technical metadata, cryptographic hashes, and file structure analysis will not tell you whether the content depicted is true, but they will tell you whether the file has been altered, re-saved, spliced from multiple sources, or does not match the provenance story it is being presented with.

Most people expect EXIF data to be the smoking gun, and with screenshots that expectation is usually disappointed. A photo taken by a phone camera typically contains a dense block of EXIF, including make and model, lens information, exposure settings, GPS coordinates, and a creation timestamp written by the camera firmware. A screenshot, by contrast, is created by the operating system screen capture pipeline, not by an imaging sensor. On iOS and Android, a native screenshot is usually saved as a PNG with very little EXIF, often just a software tag, creation date, and sometimes a color profile. Windows Snipping Tool and Snip & Sketch historically produced PNG or JPEG files with minimal metadata, and many desktop tools strip metadata entirely on save. Mac screenshots saved as PNG can include a creation timestamp in the file system but often lack camera-style EXIF fields. That absence is normal, and the presence of camera EXIF in a file that is claimed to be a screenshot is itself a red flag, unless the screenshot was taken of a photo app and the embedded image metadata was carried over through a screenshot of a screenshot workflow, which is a messy edge case worth documenting.

The practical checks start with the file itself before you even open it visually. Check the format and dimensions against the claim. An iPhone 15 Pro screenshot is 3936×2622 pixels in portrait, with a specific pixel density and a PNG with a particular color space. A Windows 11 desktop screenshot will match the monitor resolution, and a 1080p capture will not match a claimed 4K laptop display. File size relative to dimensions is informative; a heavily compressed JPEG masquerading as a lossless PNG capture, or a PNG that is suspiciously small for its resolution, suggests re-encoding. Compression artifacts, inconsistent noise patterns, and mismatched UI scaling can indicate splicing. Cryptographic hashes are essential for integrity. Computing SHA-256 and MD5 for the file gives you a fingerprint that changes with even a single byte change. If you receive the same screenshot from two sources and the hashes differ, at least one file has been edited, re-saved, or transcoded, even if the visual difference is invisible.

AI-generated screenshots are a growing problem, and they behave differently from edited real screenshots. A fake UI can be generated with perfect typography and no compression anomalies, but it will often lack the subtle operating system artifacts that a real capture contains, such as the exact status bar layout, notification badges, battery icon style for a specific OS version, or the correct pixel rendering of system fonts. It will also lack a coherent provenance chain. A real screenshot can be cross-referenced with device logs or a contemporaneous video recording; a synthetic one cannot. This is where documentation matters more than opinion. You can record the file’s technical properties in a timestamped report and preserve the original file without re-encoding, which prevents you from accidentally destroying evidence the moment you open it in an editor.

A structured way to do this is to treat the file as forensic evidence from the moment you receive it. Upload the original file without renaming it, without opening it in Photoshop, and without converting it. A service like FilesAudit will extract technical metadata, compute SHA-256, MD5 and CRC32 hashes, and produce a professional PDF report that records the file name, size, MIME type, creation and modification timestamps, and any embedded EXIF, GPS, XMP or IPTC blocks. That report is useful for journalists, lawyers, and investigators who need to show what was known and when. The platform supports 200+ supported formats, so you can process PNG, JPEG, HEIC, and even video screen recordings in the same workflow. For image-specific questions, a dedicated JPG metadata guide and a PNG metadata guide explain what tags are typical for each format and which fields are usually absent in screenshots.

Practical examples help calibrate expectations. An iOS screenshot saved as PNG will often show Software: iOS, with a Create Date matching the file system time, and no GPS. If you see GPS coordinates in a claimed iPhone screenshot, that is unusual and warrants explanation. An Android screenshot may include an Android version tag and sometimes a device model in the Software field. A Windows screenshot created with Snipping Tool is often a PNG with no EXIF at all, just basic file system metadata. If a file claimed to be a Windows screenshot carries a camera make tag like Canon or Sony, it is not a native screenshot. Similarly, a screenshot that is claimed to be from a phone but is a JPEG with high EXIF density and a camera serial number is likely a photo of a screen, not a digital capture. A photo of a screen introduces moiré, glare, bezel, and perspective distortion, all of which are detectable both visually and through metadata inconsistency. Comparing two versions of the same alleged screenshot via hashes is a fast way to spot tampering; identical visuals with different hashes mean different encoding histories.

It is important to be precise about what metadata can and cannot prove. Metadata analysis and hashing can prove that a file is identical to another, or that it has been modified since a certain point. It can document that a file lacks expected screenshot metadata, or contains unexpected camera