Image Metadata and Privacy: What to Remove Before Publishing

Images can reveal more than pixels. A photo may carry camera details, timestamps, GPS coordinates, editing software, copyright fields, color profiles, thumbnails, and asset-management notes. Some of that metadata is useful inside a production workflow. Some of it should not be published on a public website.

Metadata review belongs next to image optimization because conversion, resizing, and export steps often change metadata. If nobody decides what should be kept, the result is accidental: either sensitive fields remain in public files, or useful editorial information disappears without a record.

"Remove EXIF" is not a complete privacy workflow unless the team proves what was present, what changed, and what still remains in the file that will be published. A useful review records the before state, the conversion step, the after state, and the fields the organization intentionally keeps.

Know the Common Metadata Types#

The most familiar image metadata is EXIF, which is commonly written by cameras and phones. It may include capture date, device model, orientation, exposure settings, lens information, and sometimes GPS location.

Other metadata can include:

• IPTC fields for captions, credit, creator, and copyright
• XMP fields written by editing and asset-management tools
• embedded thumbnails
• color profile data
• software and export history
• comments or labels added by internal tools

Not every file contains all of this. The point is to inspect representative files before deciding that the folder is safe.

Remove Location and Device Details From Public Outputs#

GPS metadata is the highest-risk field for many teams. A staff photo, office image, property photo, or event image may reveal a location that was not intended for publication. Camera and device details are usually less sensitive, but they are rarely needed for normal website delivery.

For public web assets, a conservative default is to remove location data, camera serial details, internal comments, and editing history from optimized outputs. Keep archival metadata in the original asset library if the organization needs it.

This is another reason to preserve originals. Public outputs can be stripped for privacy while source files remain useful for licensing, attribution, and future editing.

Do Not Remove Attribution Blindly#

Privacy review should not become metadata destruction without thought. Some image workflows rely on credit, rights, or caption metadata. Removing those fields from the only copy of an asset can create licensing or editorial problems.

Before stripping metadata, ask:

• Does this image require photographer credit?
• Does the CMS store credit separately?
• Is copyright information needed in the published file?
• Is the original archived with full metadata?
• Does the output need a color profile for reliable display?

The safest pattern is to keep full metadata in the original, then publish a smaller output with only the fields that are needed on the public web.

Review Metadata Before and After Conversion#

Run metadata inspection on both the source and output sample. Do not assume a converter removes everything or preserves everything. Different tools make different choices, and settings may change between formats.

For a manual review, tools such as ExifTool can show metadata fields in detail. MDN's image file type guide is useful for understanding the web formats that may appear in a publishing pipeline.

The exact command depends on your environment, but the review question is simple: what information is present in the file that will be served to the public?

For a small test batch, keep both metadata evidence and conversion evidence:

mkdir -p ./reports

exiftool -json ./metadata-sample > ./reports/metadata-before.json

getwebp ./metadata-sample \
  --recursive \
  --output ./metadata-output \
  --json > ./reports/metadata-conversion.ndjson

exiftool -json ./metadata-output > ./reports/metadata-after.json

Then summarize the conversion outputs so reviewers know exactly which public files need metadata inspection:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | [.status, .file, .outputPath, (.error // "")]
  | @tsv
' ./reports/metadata-conversion.ndjson

The GetWebP CLI command reference documents the conversion flags, and the JSON output guide explains the NDJSON report. Do not treat either report as a privacy verdict by itself; compare the metadata before and after conversion.

Add Metadata Checks to the Publishing Checklist#

A lightweight checklist is enough for many teams:

1. Identify sensitive categories: people, homes, offices, events, unreleased products, legal documents, medical or financial images.
2. Inspect a sample of original files.
3. Decide which metadata fields are allowed in public outputs.
4. Convert and resize into a separate output folder.
5. Inspect the optimized outputs.
6. Keep originals in controlled storage.

This checklist should happen before bulk upload to a CMS or CDN. Finding metadata issues after publication can be awkward because cached copies may remain outside the team’s direct control.

Watch for Screenshots and Exported Documents#

Screenshots often carry a different kind of privacy risk. The file metadata may be harmless while the pixels reveal account names, browser tabs, customer records, staging URLs, admin paths, feature flags, or internal comments.

Do not treat metadata review as a substitute for visual redaction. For screenshots, inspect the image itself at full size before compression. Then check metadata as a second step.

The same applies to images exported from PDFs, slide decks, design tools, and spreadsheets. The sensitive information may be in the visible content, the file metadata, or both.

Keep the Workflow Local When Possible#

If the reason for metadata cleanup is privacy, avoid uploading the file to another service just to inspect or strip metadata. A local workflow keeps the review closer to the original asset controls. GetWebP can be part of that workflow when the goal is local conversion to WebP or AVIF while keeping source files untouched.

GetWebP's security documentation states that the CLI reads image files from disk, converts them in memory, and writes outputs locally; image bytes are not sent to GetWebP. Licensing and status checks may still contact GetWebP services, so "local" should mean local image processing, not a completely offline product claim. See the security overview before making privacy promises to clients.

If metadata stripping is a compliance requirement, use a dedicated metadata policy and verify it with metadata inspection tools. Image conversion is one step in the publishing workflow, not a substitute for a redaction process.

Metadata privacy is not about paranoia. It is about knowing what leaves the organization. Review the source, decide what the public output needs, strip unnecessary fields, and keep the original under control.