Loading today’s stories
Build1 distinct publisher2 min readPublished
Generated images arrive with three metadata layers plus a pixel signal that no metadata tool touches, and whether the signed manifest survives depends on whether anything in your pipeline decodes and writes the file again.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A C2PA manifest is a signature over specific bytes, which is why it behaves unlike any other tag in the file [12]. Decode the image to a raw bitmap and write it out again, and the signature no longer matches its subject, so the manifest fails validation and most encoders drop the box, according to the guide [12]. That is the difference between `magick generated.png -strip clean.png` and `exiftool -all=`: the first rebuilds the file from pixels, the second edits tag groups that ExifTool knows how to write [12][11].
The real variable, then, is whether anything after the generator decodes and re-encodes at all.
Two ordinary pipeline shapes give opposite outcomes. Put the model output in a bucket and serve it, and every layer rides through to the browser untouched. Resize it with sharp, and the metadata is already gone, because sharp drops it on re-encode and keeping it requires an explicit `.withMetadata()` call [14]. That default is good library design, incidentally, and it is also invisible in a code review, because the evidence for it is the absence of a method call. Pillow reaches the same result the long way: open the source, create a new `Image`, `putdata` the pixels, save, and the new object carries no `info` dict from the original [15].
EXIF is the layer everyone finds, since generators just repurpose `Software`, `ImageDescription` or a custom `Make`/`Model`, and those are trivial to read and strip [3]. Three of the four layers the guide names live in the file's metadata [1]. An EXIF-only clear takes out one of those three and leaves two, which is exactly the failure the author reports seeing repeatedly: someone clears EXIF, the viewer says no EXIF, and the XMP packet and the C2PA manifest are still in the file [2][7]. `exiftool -jumbf:all -a generated.png` returning anything is the cheap test that would have caught it [9].
The claim I would not carry across untested is "dropped by most encoders" [12]. That is a statement about the encoders the author had to hand, on the files he had to hand. For it to hold in your pipeline, two things have to be true: your encoder must not preserve unknown container boxes when it writes, and your upload path must not have a fast branch that copies same-format, same-dimension bytes through without decoding them. Neither condition is exotic, and both are checkable in an afternoon. So the transferable part of this guide is not a command. It is the instruction to re-run detection after every step, on the grounds that "it looks clean in Preview" is not verification [16].
Ranked by verification strength, evidence, and original report placement.
The guide identifies four layers of provenance worth knowing about because they do not all come off the same way: EXIF fields, XMP packets, C2PA manifests, and pixel-level watermarks such as SynthID-style signals.
Generators repurpose classic EXIF camera fields such as Software, ImageDescription, or a custom Make/Model to identify themselves; the guide calls these trivial to read and trivial to strip.
XMP packets are an XML blob in Adobe's format holding richer provenance including model name, generation timestamp and sometimes a prompt hash, living in their own segment of the file.
The C2PA standard, from the Coalition for Content Provenance and Authenticity, embeds a cryptographically signed manifest stored in a JUMBF box that records the asset's origin; because it is signed it is designed to be tamper-evident, which the guide says is why naive metadata strippers often miss it.
Pixel-level watermarks such as SynthID-style signals are baked into the pixels themselves, are not metadata at all, and no EXIF tool touches them.
The author reports a repeated mistake: someone runs a one-liner that clears EXIF, sees 'no EXIF' in their viewer and assumes the image is clean, while the C2PA manifest and XMP packet are often still sitting there.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
C2PA proves who signed, not what was true: Content Credentials are provenance, not AI detection1 distinct publisher
build
A 14,000-star watermark remover, and no detector to test it against1 distinct publisher
build
Google Makes the Visible Watermark Optional. Your Pixel Check Is Now Decoration.1 distinct publisher
build
A five-hour watermark remover, 14,000 stars, and no detector to test either side1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Checkable at a prompt, sourced to one terminal
Most of what this guide asserts is falsifiable in ten minutes: the ExifTool invocations and their expected group output, sharp's metadata default, Pillow's empty info dict, ImageMagick's re-encode. That is a better grade of grounding than an anonymous post usually offers. What is missing is anyone else's run of it — no vendor documentation for the generators named, no C2PA-side confirmation, no second engineer reporting that a re-encoded file really did lose its manifest. The author's admission that -all= may leave the JUMBF payload behind is the most honest line in the piece and also the one he leaves untested.
Nothing counted
There is no adoption record to read. The only adoption-shaped sentence in the whole story is the list of generators said to stamp their outputs, offered without a vendor page, model version or date, and nothing tells us how many pipelines strip provenance, how many platforms check for it, or how often the downstream flag the author mentions actually fires. Any number we put here would be one we made up.
Careful body, overreaching ending
The technical half of this piece underclaims if anything: 'most encoders', 'depending on your build', and an explicit refusal to pretend that deleting headers does anything to a pixel watermark. Then the closing turn hands the reader a browser-based stripper that supposedly clears EXIF, XMP and the C2PA manifest in one drag-and-drop, entirely client-side, with the tool unnamed and neither half of that promise substantiated. The overstatement lives in the recommendation, not in the engineering.
The guide that ends at a product
Look at the shape rather than the content: four layers, four commands, and then 'the pragmatic move' is a browser tool the author declines to name, published from a randomized dev.to handle with a privacy pitch aimed squarely at developers who would otherwise wire this into their own pipeline. The engineering could stand without the endorsement, which is the argument in the author's favour — as is his insistence that you verify with ExifTool afterwards, not usually the advice of someone selling a black box.
One post, no second read
We are fairly confident in the mechanism — a manifest signed over specific bytes does not survive a decode-and-re-encode — because it follows from how signing works and matches the library behaviours described. We are much less confident about the vendor list, the unnamed tool, and what any particular ExifTool build strips. With a single publisher, no vendor or standards-body response, and a piece that trails off mid-sentence in its own caveats, there is nothing in our coverage to correct the author if he is wrong.