Skip to content
CreatorPrivacyKit
Learn Blog Privacy @mollycoddle330

What a verify-after-strip check can prove

What a verify-after-strip check can prove?

On a 16 pixel JPEG made with Pillow, the before file had an EXIF block plus description GapImageDescription and maker GapMake, and a second file of the same pixels saved without that EXIF block had only a JFIF block and the width and height.

Last updated

On a 16 pixel JPEG made with Pillow, the before file had an EXIF block plus description GapImageDescription and maker GapMake, and a second file of the same pixels saved without that EXIF block had only a JFIF block and the width and height.

Last checked 2026-10-22

JPEG pair

gap.jpg was 710 bytes, blocks jfif and exif, fields Image description GapImageDescription, Camera maker GapMake, width 16, height 16. gap-bare.jpg was 634 bytes, block jfif only, width 16 and height 16. snapshot() on this site sees that difference. The pixels were a flat RGB color, not a photograph.

PDF pair

Original 1331 bytes, saved 460. The unique marker GapXmpAuthorCPK-unique-marker was in the first file and not in the second. Author GapPdfAuthor was not in the saved bytes. The second inspect reported afterXmp false and afterAuthor false.

ExifTool documents the opposite shape for its own writer: PDF edits are reversible incremental updates, and old information is never actually deleted until something like qpdf --linearize rewrites the file. A verify pass over an ExifTool output can still be clean for the parsers that only look at the live Info dictionary, while the old bytes sit later in the file. Say which parser you used.

Office pair

Property parts gone, body sentence kept. The verify note for Office says the check is those three parts, not comments or hidden text. Run it on Verify metadata removed.

Sources

Last checked 2026-10-22.

Questions

Does a clean verdict mean the file never contained the field?

No. It means the after file, as parsed by this page, no longer has the blocks and fields the parser knows. An incremental PDF update can keep old bytes that a different parser still finds.

What did the PDF pair show?

The generated PDF’s XMP marker and author string were absent from the rewritten bytes, the second parse had no XMP and no author, and the diff verdict was clean-of-readable-metadata. Page count stayed 1. Annotations and signatures were never in that file, so the verdict does not speak about them.

Related pages