What this page is for
When ExistBefore extracts metadata from a file, the result is a list of technical fields: dateTimeOriginal, producer, exifByteOrder, and so on. This glossary explains, in plain language, what each field reveals to a forensic analyst — and which combinations are integrity signals worth investigating.
Catalog version: existbefore-rationale-v1. Each entry has a stable anchor (#field-name) so the in-app tooltips, the PDF certificate footer, and external tooling can deep-link to it.
The absence of a finding is not proof of authenticity. These fields document evidence; they do not issue verdicts.
Capture & device
- Capture timestamp
dateTimeOriginal - The exact moment the camera firmware recorded the photo. Cameras write this once, at capture, and editors typically preserve it. Mismatch with file system timestamps or with XMP/IPTC dates is a strong forensic signal.
- Camera vendor
make - Vendor declared by the camera firmware. Combined with model and EXIF byte order, it fingerprints the device. A vendor that disagrees with the EXIF byte order it normally writes (see F21) suggests the EXIF block was re-encoded or the field was forged.
- Camera model
model - Model declared by the camera firmware. Cross-references with vendor and known capture defaults; useful in chain-of-custody analysis when comparing several photos that should come from the same device.
- Last writing application
software - Application that wrote the EXIF block. Camera firmware names (e.g. "Apple iOS 17.5") indicate an unedited capture; image editor names (Photoshop, Lightroom, GIMP, Affinity) indicate a derivative work. Disagreement with XMP creator tool signals a multi-tool chain of custody.
- XMP creator tool
xmpCreatorTool - Application that wrote the XMP block. Usually the editor that last saved the file. Independent of the EXIF software field; comparing the two reveals whether a single tool or a chain of tools touched the file (see F20).
- EXIF byte order
exifByteOrder - EXIF blocks are tagged either little-endian (Intel, II) or big-endian (Motorola, MM). Each camera vendor has a stable native order. Disagreement between the byte order and the claimed vendor (see F21) is consistent with downstream re-encoding or a forged Make field.
- IPTC capture date
iptcDateCreated - Capture date stored in the IPTC IIM block, often used by photo agencies and newsrooms. Mismatch with EXIF DateTimeOriginal beyond 24 hours (see F01) suggests manual editing or partial metadata rewrite.
- XMP create date
xmpCreateDate - Creation date stored in the Adobe XMP block. Mismatch with EXIF DateTimeOriginal beyond 24 hours (see F02) is a re-encoding or tampering signal.
- XMP edit history
xmpHistory - Chain of edit actions recorded by Adobe-compatible tools. Useful provenance signal — its presence is not a tampering indicator by itself, but it documents what was done to the file and when.
Location
- GPS coordinates
gps - Latitude and longitude embedded in the EXIF GPS block. High-fidelity location data — consider whether to publish the file with these still embedded (the "Include GPS" toggle removes them from the certificate; see F15).
- GPS date stamp
gpsDateStamp - Day-precision UTC date associated with the GPS fix. When it disagrees with EXIF DateTimeOriginal beyond 24 hours (see F17), GPS may have been injected after capture or the EXIF date may have been rewritten in isolation.
PDF documents
- Page count
pages - Number of pages in the document. Useful as a baseline integrity check: a page count that disagrees with what you expect to receive can indicate a swapped file.
- PDF producer
producer - Library that wrote the PDF bytes. Distinct from the creator (the application that originated the content). Examples: "Adobe PDF Library 17.0", "Skia/PDF m120". Sudden changes between revisions of the same document indicate a re-save through a different toolchain.
- PDF creator
creator - Application that originated the PDF content. Examples: "Microsoft Word", "LibreOffice", "Pages". A creator that disagrees with the producer is normal (Word generated, then re-saved by Acrobat) but worth noting in chain-of-custody analysis.
- PDF creation date
creationDate - Timestamp the document creator wrote into the PDF Info dictionary. Not signed; trivial to back-date. Useful as a self-declared anchor only — combine with the ExistBefore attestation timestamp for trustworthy temporal evidence.
- PDF modification date
modificationDate - Timestamp of the last save. When this precedes the creation date (see F03), the metadata is logically impossible and has been forged or reset.
- PDF encryption
encryption - Indicates the PDF is protected by a password, an owner permission, or a DRM scheme. Informational signal only; encrypted PDFs may still have all the forensic anomalies of unencrypted ones.
- PDF fast-web-view (linearized)
linearized - Linearized PDFs are reorganized so the first page can be displayed before the entire file is downloaded. Common in web-served PDFs; absence is normal for PDFs produced by office suites.
Office documents
- Office revision number
revision - Number of times the document has been saved. Revision 1 with thousands of words (see F12) is unusual for authored content and consistent with a paste from another source.
- Office total editing time
totalTime - Cumulative minutes the document has been open in editing mode. Zero minutes with substantial content (see F11) is consistent with paste-from-external or plagiarized content.
- Office word count
words - Word count tracked by the office suite. Cross-references with totalTime and revision number to assess whether the editing footprint matches the apparent work product.
Universal forensic
- File header (first 64 bytes)
rawHeader - First 64 bytes of the file, hex-encoded. Used to verify that the bytes match the magic-bytes signature for the claimed MIME type (see F19). Universal across file types — extracted at the dispatcher boundary regardless of MIME.
- C2PA Content Credentials validation
c2paValidation - Result of validating the embedded C2PA Content Credentials manifest. "Valid" means the cryptographic chain checks out for this file. Anything else (see F06) is a stronger negative signal than no manifest at all.
How findings cite glossary entries
The Forensic Integrity Findings rules (F01–F21) reference glossary entries by name. For example, F21 ("device byte order disagreement") cites make and exifByteOrder. Use these anchors when sharing analysis with collaborators or in legal correspondence.
Italian version: glossario campi forensi. See also: how it works, technical overview, FAQ.