EXIF: What Your Photos Are Carrying

We tagged one test photo with a full set of camera and location data, then ran it through FileFlip's own conversion engine three separate ways. Convert it from HEIC to JPG or from JPG to PNG and every tag comes out the other side, GPS included, matched to the sixth decimal place. Convert the same file to TIFF and all eleven fields vanish, because of how the TIFF writer we run handles them.

What should you check before converting a photo with EXIF data?

Look at what the two formats in your conversion actually store, not what you assume they store.

• You're going HEIC to JPG or JPG to PNG. Convert HEIC to JPG or convert JPG to PNG and the whole EXIF block, camera, settings, timestamp and GPS, travels through untouched. We measured this below.
• You're going to TIFF. The metadata does not survive the trip through FileFlip today, even though TIFF itself has a place for it. See the measured section for why.
• You want the block gone on purpose. Converting isn't a metadata scrubber. See how to remove EXIF data on purpose further down this page.

What's actually inside an EXIF block?

A short table of camera-written fields sitting alongside the pixels, not inside them.

The current version of the standard behind all of this is Exif 3.1, jointly maintained by the Camera & Imaging Products Association and JEITA, as of August 2026. Every field in that table is a tag defined there, sitting in the file next to the pixel data rather than inside it, which is exactly why a conversion can carry the pixels and drop the tags, or the other way around.

What survives when you convert the file, per format?

Whichever tags the target format's writer bothers to carry over, and that turned out to depend on the format more than we expected.

We tagged a Kodak test photo with the eleven fields in the table above, then converted it three ways with ImageMagick 7.1.2, the same library FileFlip's WebAssembly build runs, and no -strip flag anywhere in the call, matching the worker's own code. HEIC to JPG and JPG to PNG are both real FileFlip routes and both carried all eleven tags through, GPS latitude and longitude matching the source to six decimal places, about 11cm of precision. JPG to TIFF is also a real route, and it came back with zero of the eleven. Not the GPS tags specifically. All of it.

TIFF itself has a place for these tags. The Exif structure is built directly on top of TIFF's own tag layout, and writing the same fields straight into a TIFF file with a dedicated metadata tool keeps them, confirmed with the same eleven tags. What we're describing here is specifically how the TIFF writer in the ImageMagick build FileFlip runs behaves when it saves a file, not a limit of the format. If you're converting to TIFF and the metadata matters to you, don't assume it made the trip. Check the file.

Does EXIF data include your exact GPS location?

Yes, when the camera that took the photo had location access, down to about six or seven decimal places of latitude and longitude.

Our test photo's GPS tags decode to 40.741895, -73.989308, a real coordinate pair a map will happily plot to a specific building. A phone only writes these tags when its camera app has permission to read your location at the moment you take the photo. Apple's own guide to managing this describes turning it off entirely at Settings > Privacy & Security > Location Services > Camera > Never, documented here. That setting only affects photos taken after you change it. It does nothing to ones you already have.

Who can actually read the GPS data in a photo?

Anyone who has the original file and a tool that reads EXIF, which is most photo viewers, not a specialist skill.

On a Mac, opening a photo in Preview and choosing Tools > Show Inspector shows the GPS coordinates and drops a pin on a map, no extra software involved. A phone's own Photos app does the same from its info panel. The command-line tool we used for every measurement in this piece, exiftool, reads the same data from any file that still has it, in one command. None of this requires access to your phone. It only requires the file, which is why the format your conversion lands on, and whether that format's writer keeps the block, is the thing that actually controls what a stranger downloading your photo can see.

Which image formats can actually store EXIF metadata?

HEIC, JPG and PNG all have a defined place for it, and our converter uses all three correctly.

PNG's eXIf chunk is one of the newer additions to the format. The W3C PNG specification lists it as an ancillary chunk, meaning "a decoder encountering an unknown chunk type... can safely ignore the chunk and proceed to display the image." A PNG viewer built before the chunk existed just skips it rather than breaking, so an old tool showing no metadata on a PNG isn't proof the metadata is gone. It might just be a viewer that predates the chunk.

How do you remove EXIF data on purpose?

FileFlip doesn't have a metadata-strip toggle today, and neither resizing a photo through Advanced options nor picking a smaller quality setting touches the block. We checked: a photo run through FileFlip's own resize step still carried every GPS tag afterward.

For a specific file, exiftool -all= photo.jpg deletes every metadata tag in place and is the same tool this whole piece was measured with. On an iPhone, tap Options in the share sheet before sending a photo and turn off Location, which strips it from that one shared copy without touching the original in your library, per Apple's own guide. On Windows, right-click a file, open Properties > Details, and use Remove Properties and Personal Information, which offers a scrubbed copy or an in-place removal.

Common questions

Does resizing a photo in FileFlip remove its GPS data?

No. We shrank a tagged photo with FileFlip's own maxWidth option and every GPS tag was still there afterward, untouched by the resize.

Does a screenshot carry GPS data?

No, because there's no camera behind it to report a location. We checked a macOS screenshot's own EXIF and found a colour profile and a "Screenshot" tag, nothing about where it was taken.

Does converting HEIC to JPG remove the location data?

No. We measured all eleven tags, GPS included, surviving that exact conversion. See how to open HEIC files on Windows for what else does and doesn't survive going the other direction.

Is EXIF metadata the same thing as a colour profile?

No, they're different data living in the same file. EXIF is camera and shooting information; a colour profile tells a viewer how to interpret the pixel values themselves. Colour profiles, and why your photo changed colour covers what happens when that second kind of tag goes missing.

Convert your photos

FileFlip converts HEIC to JPG and JPG to PNG entirely in your browser, on a WebAssembly build of ImageMagick. Nothing uploads, there's no account, and the EXIF block travels with the file exactly as measured above, for better or worse depending on where it's headed. What a conversion actually costs you covers the same question for the other kinds of data a conversion can drop.

How we measured this

• Test photo: one image from the Kodak True Color test set, tagged with exiftool 13.55 to carry Make, Model, LensModel, Software, DateTimeOriginal, ISO, FNumber, ExposureTime, GPSLatitude, GPSLongitude and GPSAltitude, eleven fields total.
• Conversions: run with ImageMagick 7.1.2-28, the version FileFlip's worker compiles to WebAssembly, called as magick input.ext -quality 90 output.ext with no -strip flag, matching the exact call in src/workers/image.worker.ts. The HEIC input was produced the same way, by converting the tagged JPG to HEIC with the same build.
• Survival check: exiftool -s3 -TagName against each output for all eleven tags, and exiftool -c "%.6f" -GPSLatitude -GPSLongitude to compare coordinates to six decimal places.
• TIFF check, both directions: tags were also written directly into a native TIFF file with exiftool, then that file was converted to JPG with the same ImageMagick build, and the metadata was gone on that side too, confirming the writer, not just the reader, drops it.
• Resize check: the tagged JPG resized with magick input.jpg -resize 400x267 -quality 90 output.jpg, matching the order of operations in the worker's applyOptions function.
• Screenshot check: a native macOS screenshot via screencapture, read with exiftool.
• Caveat: our GPS tags were written by exiftool, not recorded by a real camera in the field, so this measures whether the conversion pipeline preserves a well-formed tag, not whether every camera writes one identically. Real camera files carry additional maker-specific tags we didn't test, which are more likely to be lost than the standard fields above, not less.

Reproduce it with magick and exiftool from the commands above; there's no dedicated script for this one yet.