Inspect Image And PDF File Evidence

Use this guide when a reviewer needs to know what the submitted image or PDF contains before deciding what the file means. focus=metadata examines the original encoded bytes. It reports bounded file structure, selected metadata claims, coverage limits, and a separate Content Credentials receipt.

For a safety or fraud-routing decision, run an appropriate routing focus such as steg, ai, edits, or all. A metadata response has action=NO_DECISION.

How the scan fits together

Original JPEG, PNG, WebP, GIF, classic TIFF, HEIF, or PDF
                         |
                         v
          POST /v1/scan  mode=secure  focus=metadata
                         |
           +-------------+------------------+
           |             |                  |
           v             v                  v
     file_evidence  content_credentials  usage_units
     structure,     bounded C2PA         2 SCU parent
     observations,  verification         + 2 SCU per analyzed
     coverage                            native PDF image
           |             |
           +------+------+
                  |
                  v
        NO_DECISION: present the evidence to a reviewer

The Playground labels this path File evidence. Select an image or PDF and upload the original file. The Playground sends mode=secure automatically. You can also call the API directly:

curl -X POST https://gateway.trymighty.ai/v1/scan \
  -H "Authorization: Bearer $MIGHTY_API_KEY" \
  -F "file=@./claim-photo.jpg" \
  -F "content_type=image" \
  -F "scan_phase=input" \
  -F "mode=secure" \
  -F "focus=metadata"

Use content_type=pdf for a PDF. The scan is synchronous. Text and structured documents return HTTP 400 with metadata_unsupported_modality; unsupported image containers, including BigTIFF, return HTTP 415. async=true, upload_id, a webhook, a reference file, and defer_enhance do not apply to this focus. Metadata PDFs are capped at 16 pages and 16 distinct native images, subject to your tier limits.

Read the result

For example, the Playground's synthetic JPEG produces these selected fields (other response fields are omitted):

{
  "action": "NO_DECISION",
  "scu_charged": 2,
  "file_evidence": {
    "schema_version": "image-file-evidence-public-v2",
    "metadata_claims": {
      "camera_make_present": true,
      "camera_model_present": true,
      "software_present": true,
      "camera_make": "Canon",
      "camera_model": "EOS R5",
      "software": "Adobe Photoshop",
      "capture_time": "2026-09-24T12:00:00Z",
      "capture_time_basis": "explicit_offset_utc",
      "gps_fix_utc": "2026-09-26T12:00:00Z"
    },
    "observations": [
      { "code": "capture_time_conflict", "effect": "contradiction", "gap_band": "one_day_or_more" },
      { "code": "exif_pixel_dimensions_differ_from_current", "effect": "context" }
    ]
  }
}

In JPEG evidence, the same capture_time_conflict code can have different effects. An EXIF capture-time claim and GPS fix-time claim less than one minute apart appear as context; a gap of at least one minute appears as contradiction. PNG, WebP, TIFF, and HEIF report metadata.chronology_code and a coarse gap band when they can compare qualified time claims. Those reports do not promise an observations[].effect entry. The timestamps are unsigned; a reported mismatch does not establish the actual capture time. A camera name, Photoshop marker, or crop-compatible dimension change is context unless another check supplies stronger evidence. Two JPEG saves at the same quality may leave no reliable metadata trace.

The Playground uses green for parsed time claims that agree and red for a material mismatch. Neutral cards show context or a check that could not reach a comparison. These colors describe the reported claims, not whether the file is authentic or safe.

JPEG v2 can return parsed capture_time and gps_fix_utc in metadata_claims. A capture time with capture_time_basis=explicit_offset_utc is converted to UTC; local_unqualified means the file supplied no offset, so do not compare it to GPS as an exact instant. A present but malformed or ambiguous value is withheld, and the corresponding presence flag can still be true. The report withholds raw GPS coordinates, arbitrary EXIF/XMP text, serial numbers, comments, and private hashes. A partial or unavailable component means that the scan cannot answer that part of the question. GIF, PNG, WebP, TIFF, and HEIF reports have partial coverage by design; read coverage.reasons before interpreting an absent signal. PDF native image children describe encoded streams reached by the bounded PDF walk. A PDF image resource does not prove that its pixels were visible on a page.

HEIF v3 adds file_evidence.structure.primary_ispe. When its status is declared, width and height are the primary item's unsigned container dimensions before HEIF rotation, mirroring, or crop properties. Other statuses (missing, ambiguous, or invalid) return null dimensions rather than guessing from a child tile. primary_transform_present only says that an irot, imir, or clap property is associated with the primary item; it does not validate or apply that transform. For example, a normal rotated HEIC can declare 3088 × 2316 while displaying as 2316 × 3088. This difference is not an alteration finding. HEIF image payloads remain undecoded on this path.

For a PDF, 3 analyzed / 3 distinct image streams can still have status=partial: the image streams were inspected, but another feature was not. For example, file_evidence.components.native_children.reasons can contain soft_mask_uninspected when an image has a transparency mask whose effects the collector has not analyzed. This is a coverage gap, not an alteration finding. A completed Flate or JPX child describes PDF pixels; it cannot recover the original photo's EXIF or capture history.

Review a PDF page by page

New PDF v2 results include one file_evidence.pages entry per page. The Playground's Simple view shows the page and its notable evidence or coverage gap. Detailed adds its MediaBox extent in points, rotation, referenced image streams, and the available metadata and observations for each stream. MediaBox is not necessarily the visible CropBox. A page without an image child does not acquire source-photo metadata from the PDF's document-level Info or XMP fields.

The API keeps page facts and image facts separate:

{
  "page_count": 2,
  "pages": [
    {"page": 1, "rotation_degrees": 0, "page_size_points": {"width": 612, "height": 792}, "coverage_reasons": []},
    {"page": 2, "rotation_degrees": 0, "page_size_points": {"width": 612, "height": 792}, "coverage_reasons": ["soft_mask_uninspected"]}
  ],
  "children": [
    {"id": "child-1", "pages": [2], "source_bytes_kind": "pdf_encoded_pixel_stream", "container": "pdf_image_xobject", "encoding": "flate", "status": "complete"}
  ]
}

This excerpt omits required fields such as each child's components. The page-2 mask gap does not negate the completed base stream or add a second image charge. The root native_children component also reports the mask reason so clients that do not render pages still see partial coverage. An uninspected inline image is likewise marked on its page with inline_images_uninspected, without adding an analyzed child or charge. Empty page reasons mean no localized coverage gap was reported; they are not a clean-page verdict. Older stored PDF v2 receipts may lack pages. The Playground says to rescan the original file for page detail rather than inventing page results. Malformed page geometry is represented by null size or rotation with malformed_metadata, not a guessed value.

For the fields and format-specific schemas, use the scan API reference. For usage examples, see SCU pricing.

Use file evidence with routing scans

The ai, edits, and all paths can include bounded file_evidence and content_credentials alongside their routing result when the collector is available. These receipts provide context for the safety or authenticity result. They do not change the selected focus or add metadata-focus SCU. Route an ordinary scan by its action and inspect its coverage before relying on an observation.

No scan here searches the public web for an earlier copy of the image. SynthID and Meta Muse watermark verification are not part of focus=metadata; a C2PA declaration about a provider is not an independently verified pixel watermark. Crops, screenshots, and recompressed files need a separately evaluated similarity-search capability.

Find a previous scan of identical bytes

When enabled for your organization, the authenticated Dashboard API can find earlier metadata scans by SHA-256 of the original file bytes:

These are Dashboard session endpoints, separate from the public gateway API key and its OpenAPI contract. A hash match means identical submitted bytes. A crop, screenshot, or re-export changes the hash and will not match. Stored metadata receipts remain until explicit deletion; billing and audit records follow their separate retention rules. A disabled feature returns HTTP 404. Do not use exact-byte lookup as an image-similarity result.