jpeg.id
  1. jpeg.id
  2. How It Works

Published 31 July 2026 ยท jpeg.id

A transparent local-analysis pipeline

How jpeg.id reads image evidence.

One static application, reviewed trust snapshots, bounded parsers, and no server that receives your image or its derived data.

Inspect an image Privacy details

From selected file to Image ID

  1. 01
    Preflight. jpeg.id detects JPEG, PNG, or WebP from magic bytes, checks byte and pixel limits, normalizes the filename, and calculates SHA-256.
  2. 02
    Provenance. Same-origin WebAssembly validates embedded C2PA data, asset binding, signature results, signer trust, and timestamp trust.
  3. 03
    Metadata. A separate worker reads bounded EXIF, IPTC, and XMP values so hostile parsing does not block the interface indefinitely.
  4. 04
    Normalization. Both evidence sources become one versioned, JSON-safe report consumed by the interface, comparison engine, and exports.

Trust is explicit and dated

jpeg.id bundles reviewed snapshots of the official C2PA signer and timestamp authority trust lists. A trusted result means the signer chains to that specific bundled snapshot; it is not a timeless or universal statement. Snapshot identity is included in normalized reports so exported evidence preserves its validation context.

Remote manifest lookup and online certificate status requests are disabled. That strengthens the no-egress guarantee but means jpeg.id cannot recover stripped remote credentials or discover revocation information published after its snapshot.

Hostile inputs receive strict limits

Image files and every value extracted from them are attacker-controlled. jpeg.id applies fixed limits to bytes, dimensions, metadata entries, value length, object depth, raw manifest retention, rendered manifest text, and parser duration. Workers are terminated after timeouts, C2PA readers are freed, and preview URLs are revoked.

A worker is not a security sandbox

Workers protect responsiveness and make cancellation practical. Browser and parser security still depends on the browser, WebAssembly runtime, dependencies, and the surrounding device.

Network behavior is part of the contract

Production tests monitor browser requests while real images are analyzed. Runtime network access is limited to same-origin application assets, workers, WebAssembly, fonts, trust snapshots, and samples selected by the user. Security headers restrict scripts, workers, connections, images, framing, referrers, and device capabilities.

There is no application backend, account, database, analytics beacon, remote font, runtime CDN, persistent browser storage, or service worker. Read the exact privacy boundary before relying on the tool for sensitive work.

Reports avoid stronger claims than the evidence

C2PA results, editable metadata, and unknowns remain distinct. Creation-method declarations never alter validation status. Operational failures never become provenance verdicts. Comparison reports observed differences and never claims lineage. This contract is shared by the interface, JSON, text, and inert HTML exports.