Check a JPEG or PNG for hidden metadata before sharing it

Decide what the public image may contain

Write a short disclosure rule before exporting: which visible names, organization details, author fields, locations, descriptions and source references belong in this particular story? Keep the authorized original privately and give the proposed public copy a distinct version. A filename can also reveal context even when it is not embedded in the picture. Do not upload private media to an unfamiliar checking service merely to obtain a reassuring result.

The PNG specification explicitly discusses Exif location information and other privacy risks. Its text chunks can also carry author, description and application-defined information. JPEG can contain separate metadata segments. These are reasons to inspect the file, not evidence that your particular image contains a real location or that a destination removes it. Our downloadable examples contain only fictional markers and simple geometric drawings; no personal photograph, real GPS record or client file was used.

Inventory families before interpreting an empty field list

Use a permitted local inspector that exposes the relevant fields and containers. Check what it actually supports. Exif, XMP, comments and image text are not interchangeable labels for one storage location. An inspector that reports no Exif has not necessarily examined XMP, compressed text, an unknown application segment or visible words inside the pixels. Keep anything you cannot inspect unresolved.

The included Python inventory reads JPEG/PNG structures locally and reports selected family presence, container types, dimensions and file identity. It deliberately does not decode every field or display private metadata values. Its local input bound is 16 MiB with a bounded number of chunks/segments; that is a tool limit, not a LinkedIn upload limit. Run python3 inspect_image.py FILE with existing Python 3. No package, network request or automatic upload is required. Use an appropriate fuller inspector when the field values themselves must be reviewed.

Follow the actual partial-cleanup result

The constructed tagged.jpg contains an Exif block, a separate XMP block and a comment. Its Exif-only derivative loses that block but retains the other two families. The selected-header-removal derivative removes those three selected families. Its compressed image scan bytes stay unchanged, but that still does not preserve how an orientation-aware viewer presents it.

PNG has its own structure. The tagged PNG contains eXIf, tEXt and iTXt chunks. Removing the selected chunks in our fixture preserves every IDAT image-data byte and the decoded pixel result. A metadata-retaining export of the JPEG instead produces a PNG with eXIf and compressed zTXt data; the local Sharp decoder still exposes XMP. Searching only for an uncompressed text marker or one family name would miss that distinction. These results describe the supplied files and runtime, not every editor or social upload.

Preserve the intended orientation and inspect the result

Our JPEG stores 160 × 100 pixels with Exif Orientation 6. The actual orientation-aware local decode is 100 × 160. Removing the tag without rotating the pixels leaves a 160 × 100 presentation. The packet’s previews show this difference using the same colored shapes and arrow. A file can therefore lose selected metadata while also changing the meaning or readability of the image.

The tested Sharp pipeline applies Exif orientation before exporting a separate PNG. Its decoded pixels match the source JPEG after the same orientation operation. This preserves the already-decoded JPEG samples; it does not recover information lost before that JPEG was made. Sharp documents that auto orientation considers Exif, while orientation elsewhere, such as XMP, remains separate. Metadata-retention options can keep other fields even after rotation. Color profiles and appearance also need deliberate handling; this small sRGB fixture does not establish behavior for every camera, HDR, CMYK or display.

1. Keep the permitted original and its intended appearance.
2. Inspect the actual metadata families and any relevant field values.
3. Create the intended public copy with documented controls in software you already have.
4. Reopen that copy and check orientation, color, visible text and selected metadata again.
5. Match the exact intended file at handoff; inspect the destination’s available copy when possible.

Leave malformed or uninspected material unresolved

The packet includes an unknown ancillary PNG chunk, trailing bytes, a truncated file, a bad CRC and an incorrectly named SVG. The family inventory holds an uninterpreted container and leaves the malformed/out-of-scope examples uninspected. It also retains a constructed eXIf-after-IDAT case. The current PNG ordering table requires eXIf before IDAT; a decoder’s willingness to show some pixels is not evidence that the file passed this check.

This inventory is not a complete implementation of the PNG or JPEG standards. It does not inspect image text, transparency concealment, all possible metadata encodings or a recipient’s private archive. In another supplied PNG, selected metadata is absent while the pixels visibly say DEMO PRIVATE. That file still fails the declared disclosure rule. A known forbidden detail is evidence of a problem; an unsuccessful search is not evidence that all private information is gone.

Verify the exact handoff and preserve the copy limits

Use the reviewed version rather than a familiar basename. A hash can help compare exact bytes, but it cannot authenticate a person or certify the picture’s meaning. One supplied case approves the oriented PNG but receives the tagged JPEG: hold the mismatch. Another has only a prepared local file and no destination observation. A third supplies matching local received-copy bytes. These are three different states, and none is a real reader or native publication test.

A destination may transform an upload or offer a separate download. Inspect the actual available result in a permitted context and record any unavailable view as unknown. Do not assume that local metadata behavior establishes LinkedIn processing, search indexing or every recipient copy. If an earlier version was already shared, a new export or later deletion does not establish recall of that old file. Keep rights, visible disclosure, credentials/provenance and audience choices as separate reviews.

Reproduce the files and use a private review record

The packet contains 17 decisions tied to actual constructed files, full localized records and blank worksheets. The read-only Python family inventory and checks use the standard library. Rebuilding the image transformations additionally uses the existing Node/Sharp 0.35.5 runtime recorded in runtime.json; the complete script is included and installs nothing. The extracted rebuild reproduces every package file byte for byte under that same runtime. These are local technical results from controlled inputs; native platform processing and a real recipient journey remain untested.

Keep your exact file, allowed disclosure, permission, actual field/container review, intended appearance, final version and any observed recipient file in a private record. The relevant current specification and API sections were read on 2 November 2026. No real media, account, image upload, recipient or provider setting was inspected or changed. A destination-specific conclusion requires its own actual permitted observation.