What Is EXIF Data, and Why Do Most Converters Delete It?

EXIF is a small file living inside your photo

EXIF stands for Exchangeable Image File Format. It's a block of structured data that cameras and phones write directly into an image file at the moment it's captured, sitting alongside the actual pixel data but entirely separate from it. Open a photo's "Details" or "Get Info" panel on any device and the fields you see — Date Taken, Camera Model, Focal Length, sometimes GPS coordinates — are almost all pulled from this block.

A typical EXIF block from a modern phone includes:

• Capture date and time — often to the second, and sometimes duplicated in three places (original capture, digitized, and file modification) which can legitimately differ if a photo was edited later.
• Camera make and model — "Apple, iPhone 15 Pro," specific enough to identify not just the brand but the exact device generation.
• Lens and exposure details — focal length, aperture, ISO, shutter speed. Genuinely useful to photographers reviewing their own shots, largely irrelevant to everyone else.
• Orientation — a flag describing how the camera was rotated, so viewers know to display the image right-side up without physically rotating the stored pixels.
• GPS coordinates — only if location services were enabled for the camera app, but when present, accurate to within a few metres. This is the field with real privacy stakes; see our piece on photo metadata privacy for what that actually means in practice.

Where it physically lives in the file

The exact mechanics differ by format, which matters for understanding why conversion breaks it:

In a JPEG, EXIF lives in an APP1 marker segment — a labelled chunk inserted right after the file's start-of-image marker, containing a miniature TIFF-structured directory of tagged fields. A JPEG decoder that doesn't care about metadata just skips straight past this segment to the actual image data.

In a HEIC file, there's no equivalent simple segment. HEIC is built on the ISOBMFF container format — the same family of box-based structure MP4 video uses — and the Exif payload is stored as one "item" among several inside a nested tree of boxes (meta, iinf, iloc), addressed by an item ID rather than sitting in an obvious, predictable spot near the top of the file. Extracting it means walking that box hierarchy properly rather than just scanning for a marker.

PNG can carry Exif in a dedicated eXIf chunk, but support for actually reading it back out is inconsistent across software, which is part of why PNG isn't a reliable place to preserve it.

The technical reason conversion deletes it

Almost every image converter — including most that market themselves as privacy-focused — works the same way under the hood: decode the source image into raw pixels, draw those pixels onto a canvas, then ask an encoder to save that canvas in the new format. This is genuinely the standard, correct way to convert an image's pixel data.

The problem is what a canvas actually is. A canvas is a grid of colour values — width, height, and a number for each pixel's red, green, blue and alpha. Nothing else. The moment an image is drawn onto one, every byte of EXIF that used to travel alongside those pixels ceases to exist, because the canvas was never a place metadata could live in the first place. The output file the encoder produces afterward is, by construction, metadata-free — not because anyone chose to delete it, but because there was nowhere for it to survive the trip.

This is why the omission is so consistent across unrelated tools built by different teams: it isn't a shared policy decision, it's a shared architectural default. Skipping it takes deliberate extra engineering; getting it by default requires nothing.

What it takes to actually keep it

Preserving EXIF through a conversion means treating it as a separate problem from the pixels entirely: read the metadata block out of the source file directly — parsing the JPEG APP1 segment, or walking the HEIC box tree — before the canvas step ever happens, hold onto it independently, and then splice it back into the newly encoded output file's own APP1 segment afterward. The pixels and the metadata take two completely different paths through the pipeline and are reunited only at the very end.

One detail that has to be handled deliberately in that process: orientation. The decoder that draws the image onto the canvas typically already applies the source orientation flag so the picture displays upright — meaning the pixels themselves are now correctly rotated. If the original orientation flag were copied across unchanged, a viewer would rotate an already-upright image a second time. The flag has to be reset to "normal" as part of re-attaching the metadata, not just copied verbatim.

This is the approach this site's own HEIC to JPG converter uses, with a toggle to switch it off if you'd rather share a file with the location data deliberately removed.

Why this is worth caring about at all

Two very different reasons, depending on what you're doing with the photo. If you're archiving family photos, metadata loss means your photo library silently starts sorting by "the day I happened to convert it" instead of the day it was actually taken — years of chronological order can quietly collapse into one pile dated today. If you're sharing a photo publicly, the same metadata that's useful in an archive becomes a liability, because GPS coordinates travel with the file to anyone who downloads and inspects it. Neither of these is solved by the same default — which is exactly why this matters enough to make a visible, on/off choice rather than a fixed behaviour.

Related

• HEIC to JPG converterMetadata preservation on by default, with an off switch
• The privacy risk in photo metadataWhat GPS coordinates in a photo can actually reveal