What Is Actually Inside Your Photo’s Metadata, and How to Strip It

Press the shutter on a phone and the file that lands in your camera roll contains more than pixels. Alongside the compressed image, most cameras write a block of structured fields describing the photo: when it was taken, on what device, with which settings, and — if location services were on for the camera — where. That block is EXIF, and it is invisible in every normal way of looking at a photo.

None of this is a secret. It is a published standard, and it exists for reasons that benefit you most of the time. But the same fields that make your photo library searchable become a disclosure the moment you hand the file to someone else. This guide covers what the fields actually are, what they can reveal in combination, whether they survive a trip through someone else’s server, and how to remove them.

Where EXIF comes from, and why cameras write it

EXIF is short for Exchangeable image file format. The wording quoted in this guide comes from Exchangeable image file format for digital still cameras: Exif Version 2.32, formulated jointly by the Camera & Imaging Products Association and JEITA and issued as CIPA DC-X008-2019 / JEITA CP-3451X (English translation, PDF, retrieved 31 July 2026). That is not the newest edition. CIPA’s standards list gives the current one as Exif Version 3.1, CIPA DC-008-Translation-2026, dated 30 January 2026 (CIPA standards list, retrieved 31 July 2026).

In a JPEG the data sits in an application marker segment near the very start of the file. The standard states that “APP1 shall be recorded immediately after the SOI marker indicating the start of the file”, and that the segment “cannot record more than 64 KBytes”. Inside it, the fields are laid out in a TIFF-like structure: “Attribute information is stored in TIFF structure including a File Header, with a maximum of two IFD (0th IFD, 1st IFD). The 0th IFD may record attribute information concerning the compressed image (primary image). The 1st IFD may be used to record a thumbnail image.”

Cameras write all of this because it is genuinely useful. The orientation field is why a photo shot sideways appears upright. Exposure fields are why you can review what you did wrong. Timestamps are why your library sorts correctly, lens data is why raw converters can apply the right distortion correction, and GPS is why a phone can show your photos on a map. The standard was designed for cameras talking to software, not for publishing on the open internet, and that mismatch is the whole problem.

The fields that matter for privacy

The standard defines well over a hundred tags. Only a handful are interesting to someone who receives your file. The names below are the tag names as defined in the standard.

Two of these deserve more than a table row. The first is MakerNote, which the standard defines as “a tag for manufacturers of Exif/DCF writers to record any desired information” whose “contents are up to the manufacturer” — so what a given vendor puts in there is a question you cannot answer from the specification. The second is the thumbnail in the 1st IFD. A small copy of the image is stored inside the metadata block, and it is a separate set of pixels from the main image. Some editors write new main pixels while copying the metadata block across unchanged, which means a cropped or retouched photo can still carry a thumbnail of what it looked like before the edit. Whether that happens depends entirely on the software, so treat it as something to check rather than something to assume.

Which fields are actually present varies a great deal. Phones and interchangeable-lens cameras populate different subsets, firmware versions differ, and a photo that has passed through two apps may have fields that neither the camera nor you put there. There is no useful general answer to “does my photo have GPS in it” — you have to look at your own file, which is the section after next.

What the fields reveal in combination

The following is a made-up scenario, not a real case, and no part of it describes a real person. It is here only to show how fields compound.

Say you photograph a bicycle you want to sell and post it to a classifieds site. The photo was taken in your hallway. On its own, GPSLatitude and GPSLongitude put a pin on a building, and GPSAltitude can narrow that to a floor in a block of flats. DateTimeOriginal says you were home at 18:42 on a Tuesday; a handful of photos from the same address establish a pattern rather than a single moment. Make and Model tell a buyer which phone is in the house.

The quietly powerful one is BodySerialNumber. It is not private information in the usual sense, but it is a join key. If the same serial appears in photos posted under a different name on a different site, those two accounts are now linked by the device, without anything in either photo being obviously identifying. Every field is minor. The set is not.

Does the platform strip it for you?

This is where most writing on the subject goes wrong, including confident lists of which services remove EXIF and which do not. I am not going to give you that list, because I cannot verify it, and a stale answer here is worse than none.

What is safe to say is why the answer is unstable. Behaviour differs between a platform’s native app and its website; between sending a photo as an image and sending it as a file or document attachment; between a resized copy served in a feed and an “original quality” or download link; and between a re-encoded image and one passed through untouched. It also changes over time, quietly, because stripping metadata is an implementation detail rather than a promised feature.

There is a second distinction that matters more than the first. A service removing metadata from the copy it serves to other people tells you nothing about what it received and what it keeps. Your upload contained the coordinates either way. Stripping on delivery is a courtesy to your audience, not privacy from your platform.

The practical move is to stop asking and start checking. Upload one throwaway photo the exact way you normally share, download the file back from the platform, and inspect the copy you get. That answers the question for the path you actually use, and it stays answered until the platform changes something. Better still, remove the metadata before it leaves your machine, so the answer stops mattering.

PNG, WebP and PDF carry their own

Metadata is not a JPEG problem. PNG defines several chunks for it: tEXt for uncompressed textual data, zTXt for compressed textual data, iTXt for international textual data, and eXIf for a full Exif profile (PNG specification, W3C, retrieved 31 July 2026).

WebP’s extended file format has the same capability. The container specification defines an EXIF chunk described as “Image metadata in Exif format” and an XMP chunk (the name is four characters, with a trailing space) described as “Image metadata in XMP format” (WebP container specification, Google, retrieved 31 July 2026). A screenshot saved as PNG or a photo converted to WebP is not automatically clean; it depends on what the converter chose to carry over.

PDFs work differently. A PDF has a document information dictionary with fields such as title, author, subject, keywords, creator, producer, creation date and modification date, and it may also carry an XMP metadata stream. Producer and creator in particular tend to name the exact software and version that generated the file. Separately, any photo placed inside a PDF is an embedded image that can bring its own EXIF along with it, so a document assembled from phone photos can contain coordinates even though the PDF itself looks like a document.

How to look inside your own photo

Before removing anything, see what is there. For the location fields on macOS, Apple documents the route in its Preview guide: open a photo, then “choose Tools > Show Location Info”, and “If Show Location Info appears in gray, the image doesn’t contain location information” (Preview User Guide, Apple, retrieved 31 July 2026).

For the complete picture, including maker notes and anything the operating system’s viewer summarises away, the reference tool is ExifTool by Phil Harvey, described on its own site as “a platform-independent Perl library plus a command-line application for reading, writing and editing meta information in a wide variety of files” (exiftool.org, retrieved 31 July 2026). Running exiftool photo.jpg prints what the file actually contains.

There are web pages that will read EXIF for you. Be aware that some of them do it by uploading your photo to a server, which is a strange trade for a privacy check. If you use one, our guide on checking whether an online tool actually uploads your files shows how to tell the difference in about a minute.

Removing it

Apple documents a share-sheet route on iPhone: in Photos, select the photos you want to share, “Tap the Share Sheet button, then tap Options”, then “Turn off Location” before sharing (Personal Safety User Guide, Apple, retrieved 31 July 2026). If your phone or photo app offers an equivalent, it is worth using when it is in front of you. For anything more deliberate, you want a step that rewrites the file.

The strip metadata tool on this site takes the simplest possible approach, and it is worth knowing exactly what it does rather than trusting the label. It loads your image, draws it once into an HTML canvas, and asks the browser to encode that canvas back out as a new file. The encoder writes only pixels, so nothing from the original metadata block survives — there is no filtering step that could miss a field, because the metadata is never carried forward in the first place. All of that happens in the page, on your machine; the file is not sent anywhere.

The honest limitations, all of which follow from that approach:

• It accepts JPEG, PNG and WebP. It does not handle HEIC, the default format on recent iPhones — convert with HEIC to JPG first, then check the result yourself, since I cannot promise what that converter carries over. It does not handle PDFs at all; there is no PDF metadata tool on this site.
• PNG input comes back as PNG. Everything else is re-encoded as JPEG at quality 0.95, which means a WebP goes in and JPEG data comes out while the download is named clean- plus your original filename, extension and all. Rename the extension to .jpg if you use it on a WebP, and expect to lose transparency, because JPEG has none.
• A JPEG is decoded and re-encoded, so you take one generation of lossy compression. At 0.95 that is normally invisible, but it is not nothing, and if you need the original bytes preserved exactly then a metadata-aware rewriter such as ExifTool is the better instrument. Use it instead of this tool for archival originals.
• Because browsers apply the EXIF orientation tag when decoding by default — the initial value of the CSS image-orientation property is from-image, which per MDN means “the EXIF information contained in the image is used to rotate the image appropriately” (retrieved 31 July 2026) — the copy you get back is drawn the way you saw it, and no longer needs an orientation tag to look right.

Whichever route you take, verify the output the same way you inspected the input. A tool that claims to strip metadata and a tool that does are different things, and the check costs seconds.

What stripping metadata does not do

Removing EXIF changes the file’s header, not its picture. Every pixel is still there, and pixels leak. A street sign, a house number, a distinctive view from a window, a reflection in a kettle, a screen with your email open, a name badge, a number plate — none of that is metadata, and no metadata tool will touch it. If a photo is sensitive because of what is visible in it, stripping EXIF solves the wrong problem.

The same goes for anything deliberately drawn into the image. A watermark added with the watermark tool is part of the pixels and survives stripping, which is the point of a watermark. Filenames are worth a thought too: a name like IMG_20240104_184233.jpg carries a date whatever the header says, and the file’s creation time on disk is separate from anything inside it.

And metadata removal is not retroactive. If you have already sent the original, cleaning your local copy changes nothing about the one you sent. The habit worth building is to strip before sharing rather than after wondering.