Which Files Contain EXIF Data, and How to Check Yours

Which Files Contain EXIF Data, and How to Check Yours

Two things decide whether a file carries hidden metadata: the format it is saved in, and what created it. JPEG, PNG and WebP can all hold EXIF data, but a camera writes GPS coordinates, device model and capture time into it, while an operating system saving a screenshot writes a timestamp and little else. A document you scanned with your phone's camera is a camera photo in every respect that matters here.

You rarely need to guess, because the file can show you. The section below covers how to check the file in front of you and what the result means, then the entries go deeper into how JPEG, PNG and WebP store metadata, what screenshots really contain, and why phone-scanned IDs and receipts deserve a scrub before they go anywhere.

Checking the file you are about to share

Format support only tells you what a file could hold, not what it does hold. What a file actually carries depends on the device and the app that wrote it and on every program that saved it since, so the reliable answer comes from reading the file itself rather than going by its extension.

Every common image format can carry it

JPEG is the format the Exif standard was written around, and the newer formats caught up. The current PNG specification defines an eXIf chunk for Exif data, and the WebP container defines an EXIF chunk and an XMP chunk for metadata.¹² Saving a photo as PNG or WebP is therefore no guarantee that its location went away; a converter that copies metadata across keeps it.

What usually decides the outcome is the program doing the saving. A phone camera writes a full block on capture, an editor may copy that block into every export, and a screenshot tool starts from nothing, which is why two PNG files can differ completely in what they reveal even though the format is the same.

Reading the field list

Drop the file into the EXIF scrubber and read the fields it lists before you remove anything. GPS latitude and longitude, a camera make and model, or a lens serial number mean the file came from a camera or kept a camera's metadata. A short list with only dimensions, a timestamp or a software name is typical of a screenshot or an export that already dropped the camera data.

An empty list is a result too, and it means the file has nothing hidden for the scrubber to remove. That does not make the image safe to share on its own: a visible map, a street sign or an address on a scanned letter sits in the pixels, where only cropping or blurring removes it.

Files the scrubber cannot open

HEIC photos from iPhones, RAW files from cameras and PDF exports from scanning apps are outside what the scrubber reads. Convert or export them to JPEG first, then check and clean the JPEG, and share that copy instead of the original. Keep the original file private, because it still carries everything the conversion step may have copied over or left behind.

EXIF Metadata in PNG vs JPEG vs WebP: What Each Format Stores

JPEG, PNG, and WebP handle metadata in meaningfully different ways, which means the same photo can carry different privacy risk depending entirely on which format it was saved in. Understanding the difference helps explain why a photo exported from your phone behaves differently from a screenshot saved by an app, even when both end up as the same general kind of image file. It also helps you triage a mixed folder of images quickly: knowing each format's default behavior lets you spot the highest-risk files at a glance, without opening every single one to check.

JPEG was designed from the outset to carry a rich set of EXIF, IPTC, and XMP data, stored inside a defined segment of the file structure.¹ PNG and WebP were not built around the same assumptions, which changes what they typically carry by default.

JPEG: built for metadata from the start

JPEG stores EXIF data inside a dedicated APP1 segment of the file, which holds an entire embedded structure of camera and capture information.¹ Because JPEG is the default output format for most phone cameras (outside of HEIC) and most DSLR and mirrorless cameras, it is also the format most likely to carry a full set of GPS, device, and timestamp fields in everyday use. Consequently, JPEG photos straight off a camera or phone are the highest-priority files to check before sharing. The APP1 segment survives editing and re-saving through most photo software, which means a JPEG you edited weeks after capture can still expose the original GPS coordinates and timestamp unless those fields are explicitly stripped.

PNG: metadata support exists but is rarely used by capture devices

PNG has no APP1 segment the way JPEG does and stores metadata in "chunks" instead, including an eXIf chunk for Exif data, chunks for physical pixel dimensions and the last modification time, plus arbitrary text fields some editing tools use for notes or copyright.² In practice, PNG files are more often the output of screenshots, graphic design exports, or screen recordings than direct camera captures, so they tend to carry less GPS and device data even though the format technically allows it.

Why this matters for screenshots

A screenshot saved as PNG inherits the simpler metadata profile typical of OS-generated images, not a camera-style EXIF block, which is part of why screenshots carry far less risk than camera photos even when saved in a format that does support some metadata. Since the OS wrote the file without involving a sensor, the metadata footprint reflects the software pipeline rather than the physical capture conditions that produce GPS and lens readings.

How compression type affects metadata survival across saves

JPEG uses lossy DCT compression, which means every time you open, edit, and re-save a JPEG file, the image quality degrades slightly. Metadata, however, survives recompression intact as long as the editing software preserves the APP1 segment. In practice, most editors from Adobe Lightroom to Apple Photos keep EXIF data through multiple save cycles, so a JPEG that has been edited five times can still carry the original GPS coordinates and capture timestamp from the day it was first shot.

Why PNG screenshots resist generation loss

PNG uses lossless DEFLATE compression, so a PNG file can be opened, edited, and re-saved any number of times without any image quality degradation. The split traces back to the original standards: JPEG's lossy DCT coding was standardised as ITU-T Recommendation T.81 in 1992, while PNG is built on the lossless deflate algorithm, so the two formats make opposite guarantees by design rather than by accident.³ The same applies to metadata: because there is no lossy recompression step, the metadata block survives every edit cycle exactly as it was originally written. For screenshots and design assets that go through many revision cycles, PNG preserves metadata more reliably than JPEG over time.

Cross-format conversion and metadata inheritance

When you convert a file from one format to another, metadata can transfer to the destination file unless the conversion tool explicitly strips it. Converting a JPEG with full EXIF to PNG using a tool like ImageMagick copies the EXIF data into a PNG text chunk by default.⁴ Converting that PNG to WebP preserves the metadata again, since WebP supports EXIF through its RIFF container structure.⁵ A photo that started as a GPS-tagged JPEG can carry its coordinates through two format conversions and still expose location data in the final WebP file.

How the scrubber handles a mix of formats

You can clean JPEG, PNG, and WebP files one after another without changing any setting, since the tool detects whatever metadata each format carries, with each file's metadata removed according to its own container structure. The scrubber does not need to know the format in advance; it reads the file header, locates the metadata segments, and strips them regardless of whether they live in an APP1 segment, a PNG chunk, or a RIFF block.

Inside a PNG file specifically, that means checking for tEXt, zTXt, and iTXt chunks, the three chunk types PNG uses to store keyword-and-text metadata pairs, along with the tIME chunk that records a modification timestamp. A JPEG APP1 segment and a WebP RIFF EXIF chunk store their fields differently, but the underlying task is the same: locate every segment the format spec allows for metadata, and remove it. Because the scrubber checks for all of these chunk and segment types by name rather than guessing at file structure, a mixed set of files does not need sorting by format before you scrub them.

When to use this

Use this to understand why a JPEG or WebP photo straight from a camera needs scrubbing more urgently than a PNG screenshot, and check every format anyway since metadata behavior depends on the capturing app, not just the file extension.

Examples

JPEG: full EXIF block (GPS, camera, timestamp)
PNG: minimal chunk metadata (dimensions, timestamp)
WebP: EXIF and XMP support similar to JPEG

All three formats scrubbed of whatever metadata each one carries

Do Screenshots Have EXIF Data? What Gets Stored and What Does Not

A common assumption is that screenshots carry the same hidden risk as camera photos, GPS coordinates and all. That assumption is mostly false, though the absence of camera-specific fields does not mean a screenshot is entirely risk-free, only that it is lower-risk than a photo straight off a camera sensor. Screenshots are generated directly by the operating system rather than captured through a camera sensor, so they do not record aperture, shutter speed, ISO, lens data, or GPS coordinates, the fields that make camera EXIF data a privacy concern in the first place.¹

That does not mean screenshots are entirely metadata-free, though. A screenshot typically embeds a handful of fields, such as a creation timestamp and image dimensions, compared to the 30 or more fields a camera photo can carry.

Why the camera sensor is the source of the risk

Camera EXIF data exists because the camera hardware itself, the sensor, the lens, the GPS chip, generates those readings at the moment of capture. A screenshot has no sensor involved at all; it is a direct copy of pixels already rendered on your screen. Consequently, the entire category of camera-specific metadata, including the GPS tags that create most privacy concerns, simply has no mechanism to exist in a screenshot in the first place.

What an OS-generated file inherits instead

Rather than camera-sensor EXIF, a screenshot inherits the metadata conventions of the operating system that generated it, things like a creation timestamp and the pixel dimensions of the capture. These fields come from the OS image-writing routine, not from any physical sensor, which is exactly why the camera-specific risk categories never apply to a screenshot. The distinction matters because it means the risk profile of a screenshot is fixed by its origin rather than its content.

What a screenshot does carry

Screenshots typically embed a creation timestamp, image dimensions, and on some platforms, basic device or software information about how the screenshot was generated. None of this is as sensitive as GPS coordinates, but a timestamp can still corroborate or contradict a claim about when something was seen or said, which matters in some contexts even without a location attached.

A screenshot shared during a workplace chat, a customer support thread, or a legal exchange can reveal more than the sender intended if the file still carries an accurate creation timestamp. Even when the image itself looks harmless, that single metadata field anchors a message to a specific minute, which can be used to reconstruct a timeline of events.

One important exception

If the screenshot itself displays a photo that has GPS data baked into pixels visible on screen, such as a map overlay or a caption showing coordinates, that visible information is not metadata at all, and cropping or blurring the image is the only way to remove it. The distinction between hidden metadata and visible pixel content is easy to miss, but it determines whether scrubbing the file or editing the image is the right response.

When scrubbing a screenshot is still worth doing

Because screenshots carry far less risk than camera photos, scrubbing them is lower priority, but not pointless. Running a screenshot through the scrubber removes whatever fields it does carry at essentially no cost, which is a reasonable default if you are already scrubbing other images in the same batch and want consistent handling across every file type.

The consistency argument is the strongest reason to scrub screenshots along with photos. Once you adopt a rule of scrubbing every file before sharing, you stop needing to classify each image by source or content, and you remove the risk that a screenshot gets passed through with intact metadata simply because it looked too casual to worry about.

What EXIF fields screenshots actually contain on each platform

The specific metadata fields a screenshot carries depend on the operating system that generated it, not on the content visible on screen. On macOS, a screenshot saved as PNG typically includes CreationDate, ModificationDate, and the color profile information embedded by the system's display pipeline.² Android screenshots saved as PNG or JPEG add the capture timestamp and, on some manufacturer skins, the device model string.³ Windows Snipping Tool and Snip and Sketch write a similar minimal set: dimensions, color space, and a timestamp.

None of these platforms embed GPS coordinates in screenshots because the screenshot function is a software-level screen capture, not a camera capture. The operating system has no reason to tag a screen capture with location data, and the EXIF-writing routines on each platform simply do not include GPS fields for non-camera image generation. This is a structural guarantee, not a setting you need to verify.

When a screenshot inherits metadata from its source

One edge case deserves attention: if you open a photo in an image viewer, take a screenshot of it, and share the screenshot, the original EXIF data is not transferred to the screenshot file. The screenshot captures only the rendered pixels on your screen, not the metadata embedded in the source file. However, if the original photo's location data is visibly displayed on screen, such as a map widget or a photo info panel showing coordinates, that information becomes part of the screenshot's pixel data and cannot be removed by metadata scrubbing.

This same limitation shows up whenever a screenshot captures a map, a location pin, or coordinates rendered directly on screen, regardless of which app displayed them. A ride-sharing confirmation, a delivery tracking screen, or a check-in post can all render a location visibly enough that anyone viewing the screenshot can read it directly off the image, no metadata extraction required. Because that information sits in the pixels rather than a metadata field, running the file through a metadata scrubber changes nothing about what a viewer can see.

Why screenshots of sensitive content still benefit from a scrub

Screenshots of private messages, financial records, medical portals, or legal documents carry a different kind of risk than the content visible on screen. The metadata fields these screenshots do contain, primarily the creation timestamp, can establish when a particular piece of information was accessed or recorded. In a legal dispute, a timestamp showing a screenshot was taken before a specific event can corroborate or undermine a timeline.

When the fact that you captured something at a specific time is itself sensitive, you can strip the timestamp from a sensitive screenshot to remove that temporal evidence. For most casual sharing this is irrelevant, but for anyone sharing screenshots in a context where timing could be used against them, removing the timestamp is a meaningful precaution. In a PNG screenshot that timestamp is normally carried in the tIME chunk, with any keyword-and-text pairs stored separately in tEXt, zTXt, or iTXt chunks, so a scrubber that works at the chunk level clears them all without altering the pixel data.⁴ The same round trip applies to a JPEG screenshot, where the fields sit in the same APP1 EXIF marker a camera writes, which is why one detector covers both capture paths.⁵

If you are already scrubbing camera photos before sharing, adding screenshots to the same batch takes no additional effort. The tool processes every file the same way, detects whatever fields are present, and removes them. Building screenshots into your existing scrubbing habit eliminates the mental overhead of deciding which file type deserves attention and ensures consistent handling across every image you share. Once the habit is in place, the scrubber handles both file types without any extra thought from you.

When to use this

Use this if you want consistent metadata handling across every image type you share, including screenshots, even though screenshots carry far less risk than camera photos.

Examples

Screenshot: Creation date, dimensions, device info (no GPS, no camera fields)
Camera photo: GPS, camera model, lens, aperture, shutter speed, ISO, timestamp, and more

Both files cleaned to contain no metadata fields

EXIF Metadata in Phone-Scanned Document Photos

A scanned document feels like a digitized piece of paper, but the camera underneath captures it exactly the same way it captures any other photo. Scanning a receipt, an ID, or a contract with a phone's camera or a scanning app produces an image file through the phone's camera sensor, and most scanning apps are explicitly marketed around the visible cleanup they perform, cropping the edges and boosting contrast, which is part of why users assume metadata gets handled too. Consequently, the file inherits the same EXIF metadata as a regular photo: GPS coordinates of where the document was scanned, the device model, and a timestamp.¹

This surprises many users, since a scanned document feels more like a digitized piece of paper than a photograph. Functionally, though, it is a photograph, and it carries every privacy concern that a photo carries, layered on top of whatever sensitive information is visible in the document itself.

Why a scanned ID or receipt is a higher-stakes file

A typical vacation photo with GPS metadata exposes a location. A scanned document with the same GPS metadata exposes a location associated with a piece of identifying paperwork, an ID card, a lease, a medical form, which raises the stakes of what that combination reveals if the file ends up somewhere unintended. The document content itself already carries sensitive detail, and layering precise coordinates and a timestamp on top of that detail turns a privacy inconvenience into a genuine safety concern. Furthermore, many scanning apps automatically enhance contrast and crop the image, but this processing typically does not touch the underlying EXIF block at all,¹ so the metadata survives the enhancement step untouched.

What scanning apps usually do and do not handle

Most phone scanning apps focus their processing on the visible image: cropping to the document edges, correcting perspective distortion, and boosting contrast for readability. These transformations operate on pixel data, not on the EXIF block sitting separately in the file structure, since EXIF is organised into its own Image File Directories alongside the image data rather than being part of it,² so a scanned document that looks cleanly cropped and high-contrast can still carry the exact same GPS and device metadata as an unprocessed photo taken moments earlier.³ A quick way to verify whether your scanning app left anything behind is to open the file in the scrubber before sharing it. The tool displays whatever metadata fields are present, so you can see immediately whether GPS coordinates or device information survived the scanning app's cleanup pipeline.

Where scanned document photos typically end up

Scanned documents are frequently emailed to landlords, uploaded to insurance portals, or attached to job applications, often without a second thought about metadata since the focus is entirely on the document's content. Because these destinations are often outside your control once submitted, scrubbing the image before sending is the only point at which you have full control over what metadata travels with the file.

Treating every scan the same way

Applying scrubbing consistently to every scanned document, not just the ones that look sensitive, removes the judgment call of deciding which file matters enough to bother with. A receipt and a lease get the same treatment under this approach, since the cost of scrubbing an unimportant file is far lower than the cost of forgetting to scrub an important one.

Why scanned documents shared with government agencies still carry metadata risk

Government portals for benefits applications, tax filing, immigration, and court filings routinely accept photo uploads of supporting documents. These portals are operated by organizations with varying levels of technical sophistication, and their image processing pipelines are not uniformly documented. A document photo uploaded to a county clerk's portal may pass through a different processing chain than one uploaded to a federal benefits system, with no guarantee that either strips metadata.

The stakes are particularly high because these uploads often contain the most sensitive documents a person possesses: Social Security cards, tax returns, birth certificates, and immigration papers. A metadata leak from one of these files combines precise location data with legally identifying information, creating a compound exposure that is difficult to remediate after the fact.

Why PDF output from scanning apps does not solve the problem

Many scanning apps offer PDF export, which some users assume is inherently metadata-free. In practice, PDF files can contain XMP metadata, document creation timestamps, and producer software identifiers embedded in the file structure.⁴ The EXIF Scrubber tool processes image files (JPEG, PNG, WebP), not PDFs, so a PDF export requires a separate verification step. If you convert a scan to JPEG before you check it, running the file through the scrubber provides a known-clean image, which can then be re-exported to PDF using a tool that does not re-embed metadata.

How timestamp metadata on scanned documents can be used against you

A scanned document with an intact creation timestamp establishes when the document was photographed, which can be used to corroborate or challenge a claimed timeline. In a legal dispute, an insurance claim, or an employment case, the metadata on a scanned document can become evidence that supports or undermines the person who submitted it. A tenant who claims a repair request was submitted on a specific date, but the scan's timestamp shows a different date, faces a credibility problem that could have been avoided by scrubbing the file. The relevant tag is DateTimeOriginal, the capture time recorded by the camera, which ExifTool documents as distinct from the digitised and file-modified times stored alongside it.⁵

This is not a reason to scrub metadata to deceive; it is a reason to scrub metadata so that the document's content speaks for itself without the timestamp creating an unintended secondary claim. Removing the timestamp ensures the file is evaluated on its visible content alone, without metadata introducing questions that have nothing to do with the document's actual meaning.

A pre-submission checklist for any scanned document

Before uploading a scanned document to any portal, run through a quick checklist: convert to JPEG if the source is PDF, scrub the JPEG to remove all EXIF fields, verify the scrubbed file shows no metadata in the tool's display, and upload only the cleaned version. This takes under thirty seconds per document and eliminates the most common source of unintended information leakage in document submissions.

The checklist works precisely because it treats every scan identically, the same principle that makes consistent scrubbing more reliable than judging each document by how sensitive it looks. A receipt from a coffee shop and a scanned lease agreement move through the same four steps, so you never have to pause and decide whether this particular file is important enough to bother checking. That removes the single point of failure inherent in a judgment call: the file you decide to skip is exactly the one most likely to matter later.

When to use this

Use this before emailing, uploading, or sharing any document photo captured with a phone camera or scanning app, including IDs, receipts, leases, and forms.

Examples

GPS Latitude: 29.7604° N
GPS Longitude: 95.3698° W
Camera: iPhone 13
Date: 2026-06-01 09:30:12

GPS, camera, and timestamp fields removed before the file is sent