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

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 does not have a dedicated EXIF block the way JPEG does, but it does support metadata through "chunks," which can include some EXIF-style fields like physical dimensions and timestamps, 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 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 mixed-format batches

You can clean a mixed batch of JPEG, PNG, and WebP in one drop, since the tool detects whatever metadata each format carries and processes every file in a single pass, 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 batch upload does not require you to sort files by format before processing 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