Photo Metadata Explained: EXIF, GPS, XMP and Content Credentials

A photo file carries far more than pixels: Exif camera data, GPS latitude and longitude, capture times, an embedded thumbnail, XMP and IPTC description fields, and on newer cameras a signed C2PA Content Credential. Location is the field that hurts. Turn off location in the camera, share with location switched off, and strip GPS before you post anything sensitive.

Most people meet photo metadata only when a map view in their gallery app shows every picture pinned to the street where it was taken. That same data travels with the file when you email it, upload it or hand it to a web form, unless something along the way removes it. This post goes one level deeper than our look at GPS and GNSS evolution and location privacy. It explains which standards define each metadata block, what a GPS tag looks like byte by byte, what the platforms we checked say they do with location, how Content Credentials are signed and how they differ from Exif, and how to inspect and strip metadata from JPEG, HEIC and video files on the command line and inside a web application.

Key takeaways

• Photo metadata comes in layers defined by different bodies: Exif (CIPA with JEITA, current edition Exif 3.1 published 30 January 2026), XMP (created by Adobe, an ISO standard as ISO 16684-1 since 2012), IPTC Photo Metadata (current edition 2025.1) and C2PA Content Credentials (version 2.3 of the Technical Specification is the edition the C2PA specifications site offers for download).
• GPS position lives in its own Exif directory: latitude, longitude and altitude stored as fractions, plus a UTC time of fix, speed, direction and positioning error. Precision is often good enough to identify a house.
• Location leaks are not theoretical. In a March 2012 article the US Army described a 2007 incident in Iraq in which photos uploaded to the internet let the enemy determine the exact location of newly arrived helicopters inside a compound; a mortar attack destroyed four AH-64 Apaches.
• Platforms differ, and only their own documentation tells you what they do. Apple documents a per-share Location toggle. Google Photos documents that camera-recorded locations travel with shared photos unless you change sharing settings, and that a downloaded original keeps its location. Wikimedia Commons keeps Exif and reads GPS into the file page.
• Content Credentials are signed with X.509 certificates and hashed against the file. They record provenance, not truth, and they can carry location too. The C2PA explainer itself says a manifest can be removed, which is why "durable" credentials add watermarks or fingerprints.
• Thumbnails, HEIC auxiliary images, maker notes, video location atoms and file names all leak beyond the obvious Exif fields.
• For web apps, the reliable pattern is decode, re-encode and drop metadata on the server, as the OWASP File Upload Cheat Sheet recommends, then verify the output.

What metadata does a photo carry?

Think of a modern photo file as a container with several labelled drawers. The pixel data is one drawer. The rest are metadata, written by different software at different times and defined by different standards.

Exif: the camera's own record

Exif (Exchangeable image file format) is the oldest and most common block. The standard is published by the Camera and Imaging Products Association (CIPA) as CIPA DC-008, developed jointly with the Japan Electronics and Information Technology Industries Association (JEITA). CIPA's standards page lists "CIPA DC-008-Translation-2026, Exchangeable image file format for digital still cameras: Exif Version 3.1", published 30 January 2026 and described as a revision of CIPA DC-008-2024. Exif 3.0 was the 2023 edition that many tools and articles still reference.

Exif borrows the TIFF structure: a series of Image File Directories (IFDs), each a list of numbered tags with a type and a value. In a JPEG the whole structure sits in an APP1 segment near the start of the file. The important directories are:

• IFD0, which describes the main image: make, model, orientation, the software that last wrote the file and the modification date.
• The Exif IFD, which holds capture settings: exposure time, aperture, ISO, focal length, lens model, flash, white balance, and the original capture time (DateTimeOriginal) with its time zone offset.
• The GPS IFD, covered in detail below.
• IFD1, which describes an embedded thumbnail, usually a small JPEG.
• Maker notes, a vendor-specific blob inside the Exif IFD whose layout each camera maker defines. Maker notes can include serial numbers, lens serial numbers, shutter counts and internal settings. ExifTool's own documentation warns not to delete all metadata from proprietary RAW files because the maker notes can hold information needed to convert the image.

Exif is written by the device at capture time. Most of it is technical and boring. A few fields are personal: the GPS block, capture times, body and lens serial numbers, and owner name fields some cameras let you set.

XMP: the extensible layer

XMP (Extensible Metadata Platform) was created by Adobe. Adobe's developer documentation describes it as "a file labeling technology" for embedding metadata into files during creation, notes that the SDKs are open source, and states that XMP has been an ISO standard (ISO 16684-1) since early 2012. XMP is serialised as RDF/XML, so it is text, and it can be embedded in JPEG, TIFF, PNG, PDF, video formats and more, or stored in a separate sidecar file next to a RAW image.

XMP matters for privacy for two reasons. It is where editing software writes things: titles, descriptions, keywords, ratings, the editing history some applications record, and face region labels with people's names. And it can hold its own copy of GPS data in the exif: namespace, so removing the Exif GPS block alone does not always remove location.

IPTC Photo Metadata: the newsroom layer

The International Press Telecommunications Council maintains the IPTC Photo Metadata Standard. The current specification, version 2025.1 rev 1 dated 26 November 2025, includes IPTC Core schema 1.5 and IPTC Extension schema 1.9. The standard grew from the Information Interchange Model (IIM), which IPTC says has been in use since 1995, and today IPTC properties are written mostly as XMP with a legacy IIM copy in some files.

IPTC fields were designed for agencies and archives: creator, credit line, copyright notice, caption, keywords and licensing. They also include fields with obvious privacy weight, such as "Location Created", "Location Shown in the Image" and "Person Shown in the Image", and the "Digital Source Type" property that labels whether an image is a digital capture, a composite or produced by a trained algorithm. These are usually filled in by people or by software, not by the camera.

C2PA Content Credentials: the signed layer

Content Credentials come from the Coalition for Content Provenance and Authenticity (C2PA). The C2PA explainer describes a Content Credential, also called a C2PA Manifest, as "a cryptographically bound structure that records an asset's provenance". A manifest holds assertions (statements about origin, edits and the use of AI), a claim that references those assertions and binds them to the file, and a signature over the claim made with an X.509 certificate. We cover how this works, and how it differs from Exif, in its own section below.

Things that are not formally metadata but leak anyway

• File names. Some devices and apps name files after the date and time of capture, and sync tools sometimes include an account or device name in a path.
• The embedded thumbnail. IFD1 holds a smaller copy of the image. If an editor rewrites the main image but leaves the old thumbnail untouched, a cropped or blurred area can survive in the preview.
• HEIC auxiliary images. HEIF containers can hold more than one image item: the primary image, a thumbnail, depth maps and gain maps used for HDR display. The image library sharp, for example, has separate keepGainMap and withGainMap options, which tells you the gain map is a distinct piece of data that tools treat on its own.
• Video metadata. Phone videos carry location in QuickTime atoms rather than Exif. ExifTool's QuickTime tag reference lists location.ISO6709 (read as GPSCoordinates), location.accuracy.horizontal and the older ©xyz user data atom. Some cameras and drones also record a per-frame GPS track as an embedded data stream.
• Motion and live photos. A still can be paired with a short video clip, either embedded in the same file or stored as a separate one. Each part has its own metadata.

Inside the GPS tags

The GPS IFD is a small directory with its own tag numbers. ExifTool's GPS tag table lists them with the Exif data types:

ExifTool notes that when adding GPS data you must set latitude, longitude and their reference tags together, and altitude with its reference if known; the reference tag is what turns an unsigned number into north or south, east or west.

Worked example 1: decoding a latitude

An unsigned rational is two 32-bit integers, a numerator and a denominator. Suppose a file stores:

• GPSLatitude = 39/1, 21/1, 6612/100
• GPSLatitudeRef = N

Decoding gives 39 degrees, 21 minutes and 66.12 seconds. In decimal degrees that is 39 + 21/60 + 66.12/3600 = 39 + 0.35 + 0.018367 = 39.368367 degrees north.

How precise is that? One second of latitude is roughly 31 metres on the ground, so the hundredths of a second in this example resolve to about 0.3 metres. The format can easily store more precision than the phone's receiver actually achieved, which is why GPSHPositioningError exists. Either way, the stored value is in the right building, often the right room.

Worked example 2: the C2PA specification's own sample

The C2PA Technical Specification includes a sample metadata assertion with Exif GPS fields written in XMP style: "exif:GPSLatitude": "39,21.102N" and "exif:GPSLongitude": "74,26.5737W", with an altitude of 100963/29890 metres and a time stamp of 18:22:57 on 2019:09:22.

This format is degrees and decimal minutes. Latitude: 39 + 21.102/60 = 39 + 0.3517 = 39.3517 degrees north. Longitude: 74 + 26.5737/60 = 74 + 0.442895 = 74.442895 degrees, and the W makes it negative, so minus 74.442895. Altitude: 100963 divided by 29890 is about 3.38 metres. Three numbers from one sample record are enough to put a pin on a map. The example also shows that signed provenance data can carry exactly the same location fields as plain Exif.

Who defines each format: comparison table

How the metadata standards relate to each other

The layers overlap on purpose. The C2PA specification defines a general metadata assertion that may only use a fixed set of schemas and values, and its change log says the earlier Exif, IPTC and Schema.org specific assertions were deprecated and removed in favour of that general assertion. Its list of supported Exif properties includes the GPS fields. IPTC properties are commonly written into XMP. XMP can repeat Exif values. This is why stripping one block and leaving another is the most common way location survives a "cleaned" file.

Which platforms strip metadata on upload, and which keep it?

The honest answer is that it depends on the service, the upload path and whether the service gives viewers the original file or a re-encoded copy. We describe only what each provider's own documentation says, and we checked only a handful. If a service you rely on is not listed, look for its own help page, and test it with a photo you do not mind sharing using the verification steps later in this post.

Three things stand out.

First, location sharing is often a per-share decision. Apple's Location toggle under Options applies to the share you are making. Google Photos lets you control location for each shared album, link and conversation. Neither is a global "never send location" switch; the global switch is the camera's own location permission.

Second, services that host originals behave differently from services that re-encode. A photo-sharing site that serves your original file for download serves its metadata with it. A service that re-encodes images to resize them may drop metadata as a side effect, but unless its documentation says so, treat that as an implementation detail that can change.

Third, the in-app view is not the file. Google's help page makes this explicit: edits you make to locations inside Google Photos do not change the location saved in a file you download and send elsewhere. What you see in a gallery app's info panel is the app's database, which may differ from the bytes in the file.

How phone camera location settings work

Location gets into a photo because the camera app asks the operating system for a fix at capture time and writes it into the file. Turn off that permission and there is nothing to strip later.

iPhone and iPad

Apple's Personal Safety User Guide explains that when Location Services is on for the Camera app, it uses information from mobile networks, Wi-Fi, GPS networks and Bluetooth to determine coordinates, and embeds them into each photo and video. It then gives four controls:

1. Stop collection at source. Settings, Privacy & Security, Location Services, Camera, then Never. Apple states that location metadata can be collected only if the Camera app has access to Location Services.
2. Remove from an existing photo. In Photos, open the photo, tap the info button, then Adjust Info (wording differs by iOS version), Adjust Location, and No Location.
3. Share without location. Select photos in Photos or from the camera roll, tap Share, tap Options and turn off Location. "Location Not Included" confirms it.
4. On a Mac. Select photos, then Image, Location, Hide Location.

Apple also tells you how to review what is exposed: the Map collection under Collections shows only items that have embedded GPS data. That is a quick audit of your own library.

Pixel phones

Google's Pixel Camera help describes a single switch. Open the Camera app, tap Settings at the bottom left, then More settings, and turn off Save location. The same page notes that if you leave location stamps on, you also get the photo location. Android also has an operating system permission for location per app, so a camera app that has been denied location cannot add GPS data even if its own setting is on.

Other Android phones and third-party camera apps

Camera apps differ by manufacturer, and third-party camera apps have their own settings. The dependable control is the same everywhere: the operating system's location permission for the camera app. Check it after every major operating system upgrade and after installing a new camera app.

A note on the gallery app's guesses

Some gallery services estimate a location for photos that have none, based on landmarks or nearby photos. Google Photos documents this as "estimated" location, says estimated locations are not shared, and lets you turn estimation off. An estimate lives in the service's database rather than the file, but it is still worth knowing that "no GPS in the file" and "no location in my photo app" are different statements.

Real incidents: what location tags have revealed

Dated, sourced examples help calibrate the risk.

The Army article quotes a deputy G2 explaining that for every picture taken with a GPS-equipped smartphone, the phone "will automatically embed the latitude and longitude". The lesson generalises well beyond the military. Anyone whose physical location is sensitive (people escaping abuse, journalists, activists, staff at sensitive sites, people selling items from home) can leak a home address through one uploaded photo. Apple's guidance on location metadata sits in its Personal Safety User Guide for that reason.

Location is not the only leak. Serial numbers in maker notes can tie two photos to the same camera, and the same is true of capture-time patterns. The defences below deal with the whole set.

What are Content Credentials, and how do they differ from Exif?

Exif is a set of labels. Anyone can write any value with free tools, and nothing in the file tells you whether the labels are true. Content Credentials try to solve a different problem: proving where a file came from and what was done to it, in a way that detects tampering.

How a C2PA manifest is built

The C2PA explainer and Technical Specification describe these parts:

• Assertions. Statements about the asset, for example an actions assertion listing edits ("cropped", "colour adjusted", "AI generated"), an ingredient assertion for each source file, and a metadata assertion that may include a fixed set of Exif, IPTC and XMP values.
• Hard binding. A cryptographic hash, such as SHA2-256, over the bytes of the asset. For a JPEG the manifest is embedded in APP11 segments using the JUMBF box format, and the specification lets the signer exclude the manifest's own segments from the hash while including their headers, so the manifest cannot be swapped or shortened without breaking validation.
• Claim. A structure that references the assertions by hash and declares any assertions that were redacted.
• Claim signature. A COSE signature over the claim, made with a private key and an X.509 certificate. The explainer describes an approach similar to a Merkle tree, in which hashes are included in other hashes and the final one is signed.
• Manifest store. A file can carry several manifests, one per step in its history, with each new one pointing to the previous file as an ingredient.

Validation checks that the manifest is well formed, that hashes match the current bytes, and that the signer's certificate chains to an entry on a trust list. The explainer is careful about what that proves: the specification does not judge whether the provenance data is "true", only whether it is well formed, untampered and signed by a trusted signer. Trust in what the manifest says still depends on who signed it.

Can Content Credentials leak location?

Yes, if the creator includes it. The C2PA metadata assertion supports Exif GPS fields, as the sample above shows. The specification also defines a redaction mechanism: a later editor can redact an assertion, and the actions assertion has a defined reason value, c2pa.PII.present, for redactions made because the assertion contains personal information. The explainer gives the example of a human rights organisation redacting information about the person who filmed a protest before using the footage, with the redaction itself recorded in the credential.

Device makers also have to think about linkability. Google's security blog, describing Content Credentials on the Pixel 10 lineup in September 2025, says each key and certificate signs exactly one image, so that two photos cannot be linked by comparing the signing key. Google describes this as a "One-and-Done" certificate strategy. The same post says the Pixel Camera app achieved Assurance Level 2 in the C2PA Conformance Program.

Can Content Credentials be removed?

The C2PA explainer answers this directly in its FAQ: yes, provenance metadata can be removed. That is why the specification includes "durable" Content Credentials, which pair the hard binding with a soft binding such as an invisible watermark or a fingerprint lookup, so a manifest stored in the cloud can be found again even after it has been removed from the file.

This has a practical consequence for everything in the next sections. Any re-encode that strips all metadata also strips the manifest. That is fine for a personal photo you want to share anonymously. It is not fine for a newsroom, a public body or anyone whose readers rely on provenance. We do not cover forging, transplanting or deliberately hiding Content Credentials to mislead anyone; the right approach for an organisation that needs both privacy and provenance is to use a C2PA-aware editor to redact the personal assertions and sign a new manifest that records the redaction.

Exif and Content Credentials side by side

Step by step: inspect and strip metadata with ExifTool

ExifTool is a free, open source command-line tool and Perl library written by Phil Harvey; its site lists version 13.59 at the time of writing. It reads and writes JPEG, TIFF, PNG, HEIC and HEIF, MOV and MP4, and many RAW formats. The commands below work on Linux, macOS and Windows.

Warning: these commands rewrite files. Deleting metadata cannot be undone except from a backup. ExifTool keeps a copy named file.jpg_original by default, but the -overwrite_original option removes that safety net. Work on copies, and check the path you are about to process before each block.

Step 0: copy and check the target path

# Work on copies in a dedicated folder, never on your only originals
mkdir -p ~/to-share
cp ~/Pictures/export/*.jpg ~/to-share/

# Confirm exactly which files the next commands will touch
ls -l ~/to-share/

Step 1: install ExifTool

# Debian and Ubuntu
sudo apt install libimage-exiftool-perl

# macOS with Homebrew
brew install exiftool

# Confirm the version
exiftool -ver

On Windows, download the executable from exiftool.org and follow the install notes there.

Step 2: inspect everything, with group names

# Show every tag with its group, so you can see Exif, XMP, IPTC, QuickTime and maker notes separately
exiftool -a -G1 -s ~/to-share/IMG_0001.jpg

# Show only location-related tags, as raw numbers
exiftool -a -G1 -s -n -gps:all -xmp:gps* -keys:GPSCoordinates ~/to-share/IMG_0001.jpg

# Show serial numbers, owner fields and the embedded thumbnail
exiftool -a -G1 -s -SerialNumber -LensSerialNumber -InternalSerialNumber -OwnerName -ThumbnailImage ~/to-share/IMG_0001.jpg

-a shows duplicate tags (the same value can appear in Exif and XMP), -G1 prints the specific group, -s prints short tag names, and -n disables formatting so you see decimal degrees.

Step 3: strip GPS only, keep the rest

Useful when you want to keep camera settings and copyright, but not location.

# Check the path first
ls -l ~/to-share/

# Remove GPS from the Exif GPS IFD and any XMP copies of GPS fields
exiftool -gps:all= -xmp:geotag= ~/to-share/

ExifTool's documentation draws a distinction here: -geotag= deletes only the GPS tags its own geotagging feature added, while -gps:all= removes all tags in the GPS group. The -xmp:geotag= argument removes XMP GPS tags of the kind the geotag feature writes. Run Step 2 again afterwards to confirm nothing location-related is left in another group.

Step 4: strip everything from JPEGs, keeping colour correct

ExifTool's FAQ recommends this command to safely delete all metadata from JPEG images in a directory:

# Check the path first
ls -l ~/to-share/

exiftool -ext jpg -all= --icc_profile:all -tagsfromfile @ -colorspacetags ~/to-share/

It removes all metadata except the ICC colour profile, then copies back any Exif colour space tags, adding mandatory Exif tags with default values where needed. Removing the ICC profile can shift colours, which is why the FAQ keeps it. An ICC profile does not contain location.

If you want to keep one or two fields, such as the artist and copyright, ExifTool documents copying them back after the delete:

exiftool -all= -tagsfromfile @ -artist -copyright ~/to-share/IMG_0001.jpg

Do not run -all= on proprietary RAW files (DNG is the exception ExifTool names). The maker notes in those files can be needed to convert the image. Export a JPEG or HEIC and clean that instead.

Step 5: handle HEIC files

ExifTool lists HEIC and HEIF as readable and writable. The same tag deletions apply:

# Check the path first
ls -l ~/to-share/*.heic

exiftool -gps:all= -xmp:geotag= ~/to-share/*.heic
exiftool -a -G1 -s -gps:all ~/to-share/*.heic

Two cautions. ExifTool's own "known problems" notes record that motion-photo HEIC files did not display in Google Photos after being edited by ExifTool, a problem fixed in version 13.49, so keep ExifTool current. And because HEIC is a container, the most reliable way to send a clean copy to someone else is often to convert it: exporting to JPEG and then stripping the JPEG gives you a single image with no auxiliary items.

Step 6: handle video files

Phone video stores location in QuickTime metadata. Inspect it first:

exiftool -a -G1 -s -ee -n ~/to-share/VID_0001.mov | grep -i -E 'gps|location|xyz'

-ee extracts information from embedded streams, which matters for devices that write a timed GPS track. To remove the common location keys:

# Check the path first
ls -l ~/to-share/*.mov

exiftool -keys:all= -userdata:all= -xmp:all= ~/to-share/VID_0001.mov

ExifTool's QuickTime reference notes that some date tags are part of binary structures and cannot be deleted; they are set to zero instead. If you need a clean video and do not mind writing a new file, remux it with ffmpeg and disable metadata copying. The ffmpeg documentation explains that a negative file index in -map_metadata creates a dummy mapping that disables automatic copying:

# Writes a new file; the original is left alone
ffmpeg -i ~/to-share/VID_0001.mov -map 0:v -map 0:a? -map_metadata -1 -c copy ~/to-share/VID_0001-clean.mov
exiftool -a -G1 -s -ee ~/to-share/VID_0001-clean.mov | grep -i -E 'gps|location'

Mapping only the video and audio streams drops extra data streams, such as a timed GPS track, that -c copy would otherwise carry across.

Step 7: verify, then rename

# Expect no output from a clean file
exiftool -a -G1 -s -gps:all -xmp:gps* -keys:GPSCoordinates -ThumbnailImage -SerialNumber ~/to-share/*

# Rename files so names do not carry dates or device names
exiftool '-filename=share-%.3C.%e' ~/to-share/*.jpg

Then look at the picture itself. Street signs, window views, house numbers, reflections and screens can reveal a location that no tag records.

For web applications: strip metadata on upload, server side

If your product accepts photos from users, assume their files carry location and identifiers they did not mean to publish. Relying on users to clean their own files does not work, and client-side stripping in the browser can be bypassed by anyone who posts directly to your API.

The OWASP File Upload Cheat Sheet gives the pattern: for images, "decode and re-encode to an allowed image format, explicitly removing unnecessary metadata". It adds two cautions worth repeating. Rewriting does not guarantee that all malicious content is removed. And the image processor itself handles untrusted input, so use an up to date library with restricted formats, resource limits and sandboxing. Our post on ASVS 5 requirement V14.2.8 and stripping metadata from uploads covers the verification standard side of this.

Node.js with sharp

The sharp documentation states that, by default, when keepMetadata is not used, output is converted to sRGB and "all metadata" is stripped, including any ICC profile. That makes the safe path the short one:

import sharp from "sharp";

// Default behaviour: re-encode and drop EXIF, XMP, IPTC and ICC
export async function cleanUpload(inputBuffer) {
  return sharp(inputBuffer, { limitInputPixels: 40_000_000 })
    .autoOrient()        // apply the EXIF Orientation tag, then remove it
    .resize({ width: 4096, height: 4096, fit: "inside", withoutEnlargement: true })
    .jpeg({ quality: 85 })
    .toBuffer();
}

The autoOrient() call, which sharp documents as auto-orienting from the EXIF Orientation tag and then removing the tag, keeps the image from appearing sideways once the metadata is gone. The limitInputPixels option refuses inputs larger than the pixel count you set, which is one of the resource limits OWASP asks for. Avoid keepMetadata(), keepExif() and keepXmp() on user uploads unless you strip GPS yourself afterwards; sharp documents keepMetadata (added in 0.33.0) as keeping all of EXIF, ICC, XMP and IPTC.

Python with Pillow

Pillow's Image.getexif() returns an editable Exif mapping, and saving a new image without passing exif= writes no Exif block. A re-encode looks like this:

from PIL import Image, ImageOps

def clean_upload(src_path: str, dst_path: str) -> None:
    with Image.open(src_path) as im:
        im = ImageOps.exif_transpose(im)   # apply orientation, then drop the tag
        im = im.convert("RGB")
        im.save(dst_path, "JPEG", quality=85)   # no exif= argument, so no Exif is written

Set Image.MAX_IMAGE_PIXELS to a limit that fits your product, keep Pillow up to date, and run the conversion in a worker with memory and time limits.

Verify in your test suite

# Upload a fixture photo that has GPS, fetch the stored copy, and assert no GPS remains
exiftool -s -s -s -gps:all stored-copy.jpg | wc -l    # expect 0

Keep a fixture with GPS, XMP location, IPTC location and a thumbnail, and one HEIC fixture. Run the check in CI so a library upgrade or a new "keep metadata" option does not quietly bring location back.

Decision table: what to keep for which product

Common mistakes

• Stripping Exif GPS and forgetting XMP. XMP can carry its own exif:GPSLatitude and exif:GPSLongitude. Always inspect with -a -G1 after cleaning.
• Trusting the app's info panel. Removing a location in a gallery app may change only the app's database. Google says outright that a downloaded original keeps the location the device saved.
• Cleaning the photo but not the video. Video location sits in QuickTime keys or user data atoms, and sometimes in a timed GPS track.
• Forgetting the thumbnail. If a tool edits pixels but not IFD1, the old preview can survive. A full re-encode avoids this.
• Overwriting originals. -overwrite_original on the wrong folder removes metadata you may need later for your own archive. Work on copies.
• Running -all= on RAW files. ExifTool warns against it. Export first.
• Assuming a platform strips metadata because it once did. Behaviour changes. If the service's own documentation does not promise stripping, test it.
• Client-side stripping only. Anyone can bypass your web page and post a raw file to your API. Strip on the server.
• Stripping provenance you were meant to keep. For newsrooms and public bodies, a strip-all re-encode removes Content Credentials too. Redact and re-sign instead.
• Ignoring the picture itself. No tool removes a street sign from the background.

FAQ

How do I see the metadata in a photo?

On a computer, run exiftool -a -G1 -s photo.jpg to list every tag with its group. On an iPhone, open the photo in Photos and swipe up or tap the info button; on a Mac, use the info window in Photos. Gallery apps show only a few fields, so use ExifTool when it matters.

Does a screenshot contain location data?

A screenshot is a new image created by the operating system, not by the camera, so it normally does not carry the camera's GPS data. It can still carry metadata such as creation time and device details, and its pixels can show anything that was on screen. Inspect it with ExifTool if in doubt.

Does sending a photo by email remove the location?

Email attaches the file you give it. If the file has GPS data, the recipient gets it. Google's help page states that a photo downloaded from Google Photos and emailed keeps the original location the device saved.

How do I turn off location on iPhone photos?

Go to Settings, Privacy & Security, Location Services, Camera and choose Never. For photos you have already taken, use the Location toggle under Options when sharing, or Adjust Location and No Location on the photo. These steps come from Apple's Personal Safety User Guide.

How do I stop my Pixel camera from saving location?

Open the Camera app, tap Settings, then More settings, and turn off Save location, as Google's Pixel Camera help describes. You can also deny location permission to the camera app in Android settings.

Does stripping metadata remove Content Credentials?

Usually yes. A full strip or re-encode drops the C2PA manifest along with Exif and XMP. The C2PA explainer acknowledges that manifests can be removed and describes durable credentials, which use watermarks or fingerprints to look a manifest up again. If provenance matters to you or your readers, redact personal assertions in a C2PA-aware editor rather than stripping everything.

Are Content Credentials the same as a watermark?

No. A Content Credential is signed metadata bound to the file by hashes. A watermark is a signal embedded in the pixels. The C2PA specification can use a watermark as a soft binding that points back to a stored manifest, but they are separate mechanisms.

Can someone fake Exif data?

Yes. Exif is unsigned and any value can be written with free tools, which is exactly why it cannot prove where or when a photo was taken. Content Credentials were designed to make tampering detectable, but they still depend on who signed them.

Is HEIC metadata different from JPEG metadata?

The fields are the same Exif and XMP data, stored inside a HEIF container that can also hold thumbnails, depth maps and gain maps. ExifTool reads and writes HEIC. When sending a clean copy, converting to JPEG and stripping the JPEG is often simplest.

Should my website strip metadata from uploads?

Yes, for any image that will be shown publicly. Decode, re-encode and drop metadata on the server, as the OWASP File Upload Cheat Sheet recommends, and keep a CI check with a GPS-tagged fixture.

Where Safeguard fits

Safeguard does not inspect photos, read or remove Exif data, or tell you whether a file carries location; nothing in the advice above depends on it. The fit is indirect and sits on the side of the teams that build upload pipelines. The server-side stripping step runs on image processing libraries (sharp and libvips, Pillow, HEIF decoders, ExifTool, ffmpeg) that are open source dependencies and container image layers like any other, and OWASP's own warning is that the image processor handles untrusted input. Safeguard scans repositories, container images and SBOM files, builds an inventory of the components they contain, matches them against vulnerability databases, and uses reachability analysis to rank findings by the code paths your application calls. That tells you which services carry which version of an image library, so an advisory against one of them turns into a short list of projects to update.

A photo upload service is only as safe as the decoders behind it, and image and video libraries are among the most exposed open source components a web product runs, because they parse files from strangers. The fit with photo privacy itself is indirect, but keeping those libraries inventoried and patched is part of running an upload pipeline honestly; the fork and patch route described below is early access.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a repository, reads the finding and advisory, asks before each command, edits package.json to a fixed version, and runs npm install and npm test with approval, pushing nothing. The same flow applies when a scan of your upload service shows an outdated image processing package: you ask for the upgrade, approve each step, and your metadata-stripping tests run before anything is committed.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. It suits a team that wants an inventory of the image and video libraries baked into its upload worker's container image before a privacy or security review.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It helps when you want to ask an assistant which of your projects carry a given version of an image library while you work through an advisory.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• CIPA standards list: DC-008 Exif 3.1 (published 30 January 2026)
• CIPA DC-008 download page (Exif 3.0, 2023 translation)
• Adobe: XMP documentation
• IPTC Photo Metadata overview
• IPTC Photo Metadata Standard 2025.1 specification
• C2PA and Content Credentials Explainer 2.2
• C2PA Technical Specification 2.2
• ExifTool home page
• ExifTool application documentation
• ExifTool FAQ
• ExifTool GPS tags
• ExifTool QuickTime tags
• Apple Personal Safety User Guide: Manage location metadata in Photos
• Google Pixel Camera Help: camera settings
• Google Photos Help: photo locations and sharing
• Wikimedia Commons: Exif
• Google Security Blog: Pixel and Android C2PA Content Credentials (September 2025)
• US Army: Geotagging poses security risks (March 2012)
• OWASP File Upload Cheat Sheet
• sharp: output options and metadata
• sharp: constructor options
• sharp: image operations, including autoOrient
• Pillow: Image module reference
• ffmpeg documentation

Related reading: GPS and GNSS evolution and location privacy, browser fingerprinting explained, ASVS 5 V14.2.8: strip metadata from uploads and self-hosting photos, files and calendar.

Last reviewed: 24 October 2026. Platform settings and standards editions change; check the linked documentation for the version you use.