Metadata Removal Examples

What these examples are

Every file here came out of a build script, not out of someone's camera roll.

The pictures are small generated images or clearly disclosed public test assets. The build adds controlled metadata, including zero coordinates, test serial numbers and placeholder generation text. It never invents a person, a location or a trusted signing identity. Two public assets are used where local construction was not available: a libheif test image and a C2PA test file. Their card notes identify them.

Each row below comes from the same parser and cleaning engine used by the tool. The build reads the input, cleans it, reads the output again and stores that result. No field list is written by hand for this page.

A phone photo, before and after

The first, second and sixth cards start with familiar phone or camera metadata.

The JPEG card contains device, date and GPS information inside its EXIF segment. The cleaner removes that segment without rebuilding the picture. The HEIC card stores an EXIF item in the file container instead. Its item index and data offsets change when that item is removed, while the image item remains in place. These are different container operations with the same before-and-after reading method.

The WebP card shows the chunk-based form. EXIF and XMP live in their own chunks, and the corresponding header flags must be cleared as well. A zero in the after column means the parser found no matching segment on its second read. It does not mean that a visual detector examined the pixels or that a platform made a new decision about the image.

• remove metadata from a photo

Text and credentials stored inside the file

These three cards hold information that is easy to overlook when viewing only the picture.

The PNG example stores placeholder prompt and workflow settings in a text chunk. That text is not a cryptographic origin proof. It is simply metadata written into the container, and the engine removes the chunk. The XMP and IPTC example shows separate JPEG segments. They are listed separately because a single format can carry several kinds of metadata at once.

The signed-manifest card uses a public C2PA test asset. Its manifest exists for testing, not as a claim that this site issued or trusted a credential. The cleaner removes the JUMBF segments it can identify, then checks that they are absent. That file operation says nothing about the pixels, an existing post or what a service may have recorded before the file was cleaned.

Files with nothing to find

The first file never carried the supported metadata segments. The second had already passed through the cleaner. Both produce an honest empty result rather than a list invented to make the output look busier. An unchanged file is not proof of origin, and the absence of readable fields is not an AI determination.

• clean a file in your browser

How to read the report

The left side records what the parser found; the right side comes from a fresh read after cleaning.

On this page, the field column names the group and segment, while the before and after columns show counts. Removed means the second read did not find that segment. In the full tool report, Not removed marks an item that remained despite the cleaning pass, so the conclusion stays bounded by what the engine actually saw.

The tool can save the same findings as a self-contained HTML report and a JSON sidecar. The report includes the output hash and processing scope but omits removed original values. These cards do not offer downloads; they are static evidence of the engine's reading, not replacements for running a file of your own.

• See what the report contains