What jpeg.id compares
Each image first receives its own normalized report. The comparison engine then observes differences in C2PA validation state, signer trust, detected format, dimensions, byte size, SHA-256 identity, camera model, software, capture date, GPS, and other highlighted values. Rendering and exports consume those same reports; files are not reopened to produce a different answer.
Equal SHA-256 hashes identify byte-for-byte identical files. Different hashes mean the bytes differ, but the hash alone does not explain why. A dimension or byte-size change may indicate an export, crop, recompression, metadata edit, or another transformation. The report states the observation and avoids guessing at cause.
How to compare two images
-
01
Choose a reference. Use the file whose known state matters to your question.
-
02
Choose the compared file. jpeg.id analyzes it under the same limits.
-
03
Read changed, added, and removed rows. Inspect either full report for context.
A reference label is a user-selected role, not a cryptographic assertion. jpeg.id does not claim that one file was created from the other, identify an original, or estimate JPEG quality.
Useful comparison questions
- Did a redistributed file keep the same embedded Content Credential?
- Were ordinary metadata fields removed during export or publication?
- Are two files byte-for-byte identical?
- Did dimensions, format, or file size change?
- Does each credential independently validate against the same trust snapshot?
For a credential-specific investigation, start with the four C2PA validation states. For privacy review, understand what editable metadata can reveal.
Private by construction
Both files remain in browser memory. jpeg.id serializes analysis so only one hostile input is processed at a time, disposes parser resources, revokes previews, and sends no file-derived request. Comparison exports are created locally and contain no source image bytes.