Inspect PNG, JPEG and WebP file structure

Start with the container, not the filename

The inspector verifies the leading bytes before choosing a parser. A renamed file therefore cannot enter the JPEG, PNG or WebP path merely because its extension looks familiar.

Each reported block includes its byte offset, complete length, payload length, purpose and validation status. This makes the result useful for debugging a broken export without asking a non-expert to read a hexadecimal dump.

• PNG signature and chunks
• JPEG markers and scan boundaries
• WebP RIFF and FourCC chunks
• File-boundary and trailing-data checks

Separate pixels from attached information

Image payload blocks carry compressed pixels, while metadata blocks can carry EXIF, XMP, IPTC-style resources, comments, color profiles or provenance containers. The result keeps those categories visually separate.

A metadata block can be structurally present but still contain editable or outdated values. The structure map answers what bytes exist and whether their boundaries are readable; it does not certify the truth of the fields inside them.

Use errors as a repair clue, not a verdict

A CRC mismatch, truncated marker or RIFF-size conflict can explain why one application refuses a file while another shows a partial preview. The safest response is normally to preserve the original bytes and create a fresh export from a trusted application.

The parser stops at strict chunk and file-size limits. It never tries to recover arbitrary payloads, execute embedded text or upload the file for server-side repair.

• Keep the original
• Record the JSON report
• Re-export a separate copy
• Reinspect the new file