Metadata Extracts

Metadata is information stored within, attached to, or generated about a digital file, message, webpage, or record. It may describe when a file was created, which software processed it, what device produced it, who entered an author name, where an image was captured, or how an email traveled between systems.

Metadata can provide valuable investigative leads, but it is not automatically accurate, complete, original, or authentic. Many metadata fields can be edited, removed, added, copied, or changed during routine processing.

EpsteinWiki contributors must preserve the original file, document the extraction process, protect sensitive information, and explain what the metadata does and does not establish.

Snapshot

Metadata item	Possible value	Important limitation
Creation date	May indicate when software created a file	Copying, scanning, conversion, or editing may change it
Modification date	May indicate later processing	It does not identify who made the change
Author field	May identify a configured account	It may be a template value, alias, or manually entered text
Software field	May identify an application	It does not prove who operated the software
GPS coordinates	May identify a recorded location	Coordinates can be removed, altered, inherited, or spoofed
Camera model	May identify a device type	It does not identify the photographer
Email From field	Shows the displayed sender	It may be spoofed or changed
Email Received fields	May show delivery routing	Individual fields can be incomplete or misleading
PDF producer	May identify conversion software	It does not prove document authorship
File system date	Shows how a storage system handled a file	Downloads and transfers commonly change it
Hash value	Identifies a specific byte sequence	It does not prove authenticity or truth
Filename	May preserve source context	It can be renamed at any time
Embedded thumbnail	May reveal an earlier image version	It may be outdated or unrelated
Document revision count	May suggest editing activity	Software calculates revision information differently
Metadata absence	May show stripping or conversion	It does not prove intentional concealment

The central rule is:

Metadata is evidence about a file’s recorded properties, not automatic proof of authorship, authenticity, location, intent, or truth.

---

Purpose

Metadata extraction helps contributors:

• Identify document properties
• Detect possible edits or conversions
• Compare versions
• Preserve timestamps
• Locate embedded identifiers
• Identify software and devices
• Review email routing
• Detect geographic information
• Find privacy risks
• Support chain of custody
• Compare files using hashes
• Identify missing or inconsistent fields
• Generate investigative leads
• Document the condition of a file at intake

Metadata should be interpreted alongside source provenance, document contents, surrounding records, witness testimony, legal filings, and other corroborating evidence.

---

Types of Metadata

Descriptive Metadata

Descriptive metadata helps identify or organize an item.

Examples include:

• Title
• Author
• Subject
• Description
• Keywords
• Caption
• Copyright information
• Case number
• Document identifier
• File name

Technical Metadata

Technical metadata describes how a file is structured or processed.

Examples include:

• File format
• File size
• Image dimensions
• Resolution
• Color profile
• Compression
• Codec
• Duration
• Bit rate
• Software
• PDF version
• Encryption status

Administrative Metadata

Administrative metadata supports management and access.

Examples include:

• Access restrictions
• Rights information
• Retention status
• Repository identifier
• Ingest date
• Review status
• Custodian
• Evidence ID

Preservation Metadata

Preservation metadata documents the history and integrity of a digital object.

Examples include:

• Hash values
• Provenance
• File transformations
• Storage location
• Migration history
• Validation results
• Access events
• Redaction events
• OCR processing

Embedded Metadata

Embedded metadata is stored within the file itself.

Examples include:

• EXIF
• XMP
• IPTC
• PDF document properties
• Office document properties
• Audio tags
• Video container information
• Embedded thumbnails
• Comments
• Revision fields

External Metadata

External metadata exists outside the file.

Examples include:

• Website download date
• Server response headers
• Archive capture date
• Email envelope information
• Cloud storage history
• File system timestamps
• Repository record
• Court docket entry
• EFTA identifier

External metadata must not be confused with information embedded in the file.

---

Preserve Before Extraction

Never perform analysis on the only available copy.

Required Copies

When lawfully possible, maintain:

• Received original
• Preservation master
• Working copy
• Public use copy

The received original and preservation master should remain unchanged.

The working copy may be used for:

• Metadata extraction
• OCR
• Page extraction
• Redaction
• Annotation
• Format conversion
• Image enhancement
• Transcription

The public use copy should contain only information approved for publication.

Intake Record

Before opening or modifying the file, record:

• Evidence ID
• Original filename
• File extension
• File size
• Source
• Source address
• Download or receipt date
• Person who received it
• Storage location
• EFTA identifier when applicable
• Docket or exhibit information
• Initial hash
• Known access restrictions
• Known privacy risks

Opening a file in some applications may update metadata. Preserve and hash the original before routine editing.

---

Hash Values

A cryptographic hash converts a file’s byte sequence into a fixed value. Matching hash values can help confirm that two files are byte for byte identical.

EpsteinWiki should normally record a SHA 256 value for significant original evidence files.

The National Institute of Standards and Technology Secure Hash Standard describes approved hash algorithms used to detect whether digital data has changed.

Record

For every hash, record:

• Algorithm
• Complete value
• File name
• File size
• Date calculated
• Tool
• Tool version
• Contributor
• Copy that was hashed

Recalculate After Meaningful Events

Hash again after:

• Transfer
• Migration
• Recovery
• Redaction
• OCR
• Conversion
• Page extraction
• Compression
• Publication preparation

Each derivative should have its own hash.

What a Matching Hash Proves

A matching hash supports the conclusion that two compared files contain the same bytes.

What a Matching Hash Does Not Prove

A matching hash does not prove:

• Who created the file
• Who authored the content
• Whether the content is true
• Whether the file was authentic before intake
• Whether the file is complete
• Whether the source obtained it lawfully
• Whether the file was manipulated before hashing
• Whether a screenshot accurately represents its source

Do not describe a file as authenticated solely because its hash remained stable.

---

Extraction Tools

Use trusted tools that can produce repeatable output.

Common Tools

Tool or method	Primary use
ExifTool	Reads metadata from many document, image, audio, and video formats
PDF document properties	Reviews PDF title, author, software, dates, permissions, and structure
MediaInfo	Reviews audio and video container and codec information
FFprobe	Extracts technical information from audio and video files
Email View Original	Displays message headers, routing, identifiers, and authentication results
Browser developer tools	Reviews response headers and loaded resources
Archive record	Documents a webpage capture and timestamp
SHA 256 utility	Calculates a file hash
File identification tool	Compares extensions with detected file types

ExifTool can read, write, and edit metadata. Use read only extraction on preserved evidence.

Do Not Upload Sensitive Files to Unknown Services

Online metadata viewers may retain uploads, log access, process files through third parties, or expose restricted material.

Do not upload:

• Survivor records
• Minor information
• Sealed records
• Confidential source material
• Restricted evidence
• Private communications
• Medical information
• Suspected child sexual abuse material

Use approved local tools for sensitive evidence.

Record the Tool

Every metadata extract should identify:

• Tool name
• Tool version
• Operating system when relevant
• Extraction date
• Extraction time
• Time zone
• Command or settings
• Output format
• Contributor
• Errors or warnings

A metadata report without extraction details may be difficult to reproduce.

---

Document and PDF Metadata

Documents may contain more than the visible page content.

Common PDF Fields

Review:

• Title
• Author
• Subject
• Keywords
• Creator
• Producer
• Creation date
• Modification date
• PDF version
• Page count
• Page size
• Encryption
• Permissions
• Embedded files
• Digital signatures
• Fonts
• Forms
• JavaScript
• OCR text
• Comments
• Annotations
• XMP data

Creator and Producer

The creator field may identify the application that generated the source content. The producer field may identify the software that converted or wrote the PDF.

These fields do not automatically identify the author.

Example:

• Creator: Microsoft Word
• Producer: Adobe PDF Library

This may support a conclusion that a document passed through those applications. It does not prove who used them.

Creation and Modification Dates

A PDF creation date may reflect:

• Original document creation
• PDF conversion
• Scanning
• Export
• Download processing
• A later rewrite
• A misconfigured clock

Compare the embedded dates with:

• Filing date
• Docket date
• Email date
• Scan date
• Release date
• Visible signature date
• Surrounding records
• Other versions

OCR Layers

OCR may create searchable text that differs from the visible page.

Inspect OCR for:

• Misread names
• Hidden text
• Text under redactions
• Duplicate pages
• Missing pages
• Incorrect reading order
• Characters substituted for numbers
• Text copied from another version

OCR output is a derivative, not the original document.

Office Documents

Word processing, spreadsheet, and presentation files may contain:

• Author
• Last saved by
• Organization
• Template name
• Revision count
• Comments
• Tracked changes
• Hidden sheets
• Speaker notes
• Document statistics
• Custom properties
• Embedded objects
• External links

Do not publish hidden personal information merely because it was embedded in a public file.

---

Image Metadata

Images may contain EXIF, XMP, IPTC, color profile, thumbnail, and application metadata.

Review

• Camera manufacturer
• Camera model
• Lens
• Exposure settings
• Image dimensions
• Orientation
• Creation date
• Digitization date
• Modification date
• GPS coordinates
• Altitude
• Software
• Copyright
• Artist
• Caption
• Keywords
• Embedded thumbnail
• Serial numbers
• Editing history
• Color profile

The IPTC Photo Metadata Standard defines commonly used fields for describing photographs. Adobe’s XMP specification provides a framework for embedding metadata across document and media formats.

Device Information

Camera or telephone model data may indicate a device type. It does not prove who possessed or operated the device.

Serial numbers may create a stronger device specific lead but still require corroboration.

GPS Data

GPS metadata may provide:

• Latitude
• Longitude
• Altitude
• Direction
• Capture time

GPS values can be:

• Edited
• Removed
• Rounded
• Copied
• Spoofed
• Inherited from an application
• Added during later processing

Do not publish GPS coordinates involving a survivor, minor, witness, private residence, or current sensitive location without review.

Embedded Thumbnails

Some files contain a smaller preview that differs from the visible edited image.

A thumbnail may reveal:

• An earlier crop
• A prior orientation
• An unedited version
• Removed background information
• An unrelated cached image

The relationship must be verified before drawing conclusions.

---

Audio and Video Metadata

Audio and video files may contain:

• Duration
• Container format
• Codec
• Frame rate
• Resolution
• Bit rate
• Audio channels
• Sample rate
• Creation time
• Encoding software
• Device information
• GPS
• Chapter markers
• Embedded artwork
• Timecode
• Editing application
• Stream identifiers

Duration Differences

Different tools may report slightly different durations because of:

• Container structure
• Variable frame rate
• Rounding
• Corruption
• Truncation
• Missing frames
• Transcoding

A duration difference does not automatically prove editing.

Creation Time

Video creation time may reflect:

• Recording
• Export
• Transfer
• Messaging application processing
• Social media download
• Screen recording
• Cloud conversion

Compare the timestamp with visible content and independent records.

Transcoded Media

Messaging services and social platforms commonly compress or convert uploaded media. A downloaded platform copy may not preserve the metadata of the original recording.

Describe it as a platform copy unless the original file is available.

---

Email Metadata and Headers

A screenshot of an email is not equivalent to the original message with complete headers.

Preserve

When lawfully available, preserve:

• Original message file
• Complete headers
• Message body
• Attachments
• Attachment filenames
• Message identifier
• Thread context
• Export method
• Source account information
• Receipt date
• Hash values

Important Header Fields

Review:

• From
• Sender
• Reply To
• To
• CC
• Date
• Subject
• Message ID
• In Reply To
• References
• Received
• Return Path
• Authentication Results
• DKIM results
• SPF results
• DMARC results
• MIME boundaries
• Content type
• Attachment information

Internet email header structures are described in RFC 5322.

From Is Not Enough

The displayed From field may be spoofed, rewritten, or altered by an intermediary.

Do not authenticate an email using the From field alone.

Received Fields

Received fields may help reconstruct delivery between mail systems. Read them carefully and compare multiple entries.

A single Received line should not be treated as conclusive because:

• Earlier fields may have been added before receipt
• Systems use different formats
• Clocks may differ
• Gateways may rewrite information
• Export tools may omit data

Authentication Results

SPF, DKIM, and DMARC results may support analysis of how a receiving system evaluated a message. They do not prove that the human named in the message personally wrote it.

Screenshots

An email screenshot may support a lead but should be labeled as a screenshot unless the original message or authenticated export is available.

---

Website and Archive Metadata

Web research may involve information outside a downloaded file.

Record

• Full page address
• Page title
• Publisher
• Visible publication date
• Visible update date
• Access date
• Access time
• Time zone
• Server response headers
• Archive address
• Archive capture date
• Page source when relevant
• Embedded structured data
• Canonical address
• Attached document addresses
• Redirects
• Screenshot filename
• Screenshot hash

Publication Dates

A visible publication date may come from:

• Page text
• Structured data
• Content management software
• Search index
• Social preview
• Archive record

These dates may disagree.

Document the source of each date instead of choosing the most convenient one.

Last Modified Headers

A server’s Last Modified value may indicate when the server believes a resource changed. It may also reflect caching, migration, restoration, or content delivery processing.

Do not treat it as the original publication date without corroboration.

Archives

An archive timestamp shows that the archive captured a version at a particular time. It does not prove that the page was first published then.

Preserve both the original page address and the archive address.

---

File System Metadata

File system metadata may include:

• File name
• File size
• Created time
• Modified time
• Accessed time
• Owner
• Permissions
• Storage path
• Extended attributes

These fields describe the copy on a particular system.

Common Changes

File system timestamps may change when a file is:

• Downloaded
• Copied
• Moved
• Extracted from an archive
• Restored from backup
• Uploaded
• Synced
• Opened
• Indexed
• Converted
• Transferred between operating systems

Do not confuse the creation time of a downloaded copy with the creation time of the original document.

Storage Paths

A path may expose:

• Contributor names
• Account names
• Organizations
• Folder structures
• Investigation names
• Device information

Remove unnecessary private paths from public extracts.

---

Timestamps and Time Zones

Timestamps must be recorded exactly before conversion.

Preserve the Raw Value

Record:

• Raw timestamp
• Displayed format
• Stated time zone
• Offset from Coordinated Universal Time
• Whether the zone is missing
• Normalized value
• Conversion method
• Known uncertainty

Missing Time Zones

A timestamp without a time zone should be treated as ambiguous.

Do not assume it represents:

• Eastern Time
• Local device time
• Coordinated Universal Time
• The author’s location
• The recipient’s location

Clock Problems

Possible explanations for unusual timestamps include:

• Incorrect device clock
• Incorrect server clock
• Daylight saving changes
• Time zone conversion
• Export behavior
• Software defaults
• Scanning
• File recovery
• Later editing
• Metadata corruption

Timeline Use

When a metadata timestamp is added to an EpsteinWiki timeline, identify it as a recorded file time rather than an independently confirmed event time.

Example:

The file metadata records a creation time of March 4, 2005, at 14:32 UTC. This does not independently establish when the underlying content was written.

---

EFTA Metadata Extraction

EFTA records must be cited using the exact identifier and linked directly to Epstein Data.

Required Intake Information

Record:

• EFTA identifier
• Direct Epstein Data address
• Download date
• Original filename
• File size
• Page count
• File format
• SHA 256 value
• PDF creation date
• PDF modification date
• Creator
• Producer
• Encryption status
• OCR status
• Embedded attachments
• Privacy concerns
• Extraction tool and version

Compare Repository and Working Copies

When a working copy is created:

1. Preserve the repository download.
2. Calculate its hash.
3. Create a separate working copy.
4. Extract metadata from both when appropriate.
5. Record any difference.
6. Assign a separate hash to each derivative.
7. Publish only the approved public copy.

EFTA Limitations

Metadata in an EFTA file may reflect:

• Government scanning
• Collection processing
• Redaction
• OCR
• File assembly
• Export
• Release preparation
• Repository processing

It may not reflect the creation of the underlying original record.

Do not attribute a metadata field to Epstein, an associate, a witness, or an agency employee without corroboration.

---

Privacy Review

Metadata may expose information that is not visible in the document.

Sensitive Fields

Review extracts for:

• Survivor identities
• Minor identities
• Home addresses
• GPS coordinates
• Personal email addresses
• Telephone numbers
• Usernames
• Device serial numbers
• Account names
• Medical information
• Therapy information
• Confidential source identities
• Internal storage paths
• Access tokens
• Passwords
• Private server names

Public Extracts

A public metadata extract should contain only what is necessary to explain the evidence.

Create a redacted public report when the complete extract contains sensitive information.

Minors

Follow the Privacy Safeguards for Minors when any metadata identifies or could help identify a minor.

Do not publish:

• A minor’s GPS location
• School name
• Device account
• Family username
• Full birth date
• Private email
• Hidden author name
• Image thumbnail exposing the child

Restricted Originals

Keep the unredacted extract in an approved restricted location when lawful and necessary.

Do not preserve suspected child sexual abuse material as part of a metadata workflow.

---

Validation and Reproducibility

Important results should be independently reproducible.

Validation Steps

1. Preserve the original file.
2. Verify the hash.
3. Extract metadata using a documented tool.
4. Save the raw output.
5. Repeat the extraction when necessary.
6. Compare results with a second tool.
7. Record differences.
8. Review the file structure.
9. Compare with visible content.
10. Obtain a second editor for material conclusions.

Tool Differences

Tools may:

• Use different field names
• Interpret dates differently
• Omit unknown tags
• Normalize values
• Display different time zones
• Read different metadata layers
• Report conflicting file types
• Calculate durations differently

A disagreement between tools is a finding to document, not a problem to hide.

Raw and Narrative Outputs

Preserve:

• Raw machine output
• Human readable summary
• Interpretation
• Evidentiary limitations
• Review notes

Do not replace raw extraction output with a manually rewritten list.

---

Metadata Extract Table

Use a standardized table when publishing material metadata findings.

Field	Entry
Evidence ID	Internal evidence identifier
Source file	Original filename
Source	Agency, court, repository, or provider
EFTA ID	Exact identifier when applicable
Source address	Direct clean link
File format	Detected format
File size	Exact byte count
SHA 256	Complete hash
Extraction tool	Tool name and version
Extraction date	Month Day, Year
Extraction time zone	UTC or recorded zone
Metadata field	Exact field name
Raw value	Value exactly as extracted
Normalized value	Converted value when applicable
Interpretation	Limited explanation
Limitations	What the field does not prove
Privacy status	Public, redacted, or restricted
Reviewer	Authorized reviewer
Review date	Month Day, Year

Example

Field	Entry
Evidence ID	EW META 0001
Source file	example-record.pdf
Source	Public government release
File format	PDF
Extraction tool	ExifTool, version recorded in case notes
Metadata field	Producer
Raw value	Adobe PDF Library
Interpretation	The file records Adobe PDF Library as the producing software
Limitations	Does not identify the author or establish when the underlying document was written
Privacy status	Public
Review status	Requires source comparison

Use generic examples in training materials. Do not place sensitive evidence in a contributor guide.

---

Evidentiary Classification

Metadata findings should be classified according to their support.

Confirmed

The field was extracted reproducibly from the preserved file, and the result is accurately reported.

This confirms the recorded field, not necessarily the historical claim suggested by it.

Supported

The metadata is consistent with independent evidence, file provenance, and surrounding records.

Suggested

The metadata creates a plausible lead but requires corroboration.

Unknown

The meaning or origin of the field cannot be determined.

Disputed

Different files, tools, sources, or experts produce materially conflicting interpretations.

Unverified

The original file, extraction process, or provenance has not been adequately verified.

Do not convert a suggested metadata lead into a confirmed historical event.

---

What Metadata Can Establish

Depending on provenance and corroboration, metadata may help establish:

• A value recorded within a specific file
• That two files are byte identical
• That two files differ
• That software processed a file
• That a file contains a recorded timestamp
• That an image contains recorded device information
• That an email contains a particular message identifier
• That a media file uses a particular codec
• That a public file contains hidden or embedded information
• That a derivative was created after intake
• That a repository copy changed

Use language such as:

• The metadata records
• The file contains
• The extracted field identifies
• The hash comparison shows
• The timestamp is consistent with
• The result suggests
• The field requires corroboration

---

What Metadata Does Not Prove

Metadata alone usually does not prove:

• Authorship
• Identity
• Intent
• Knowledge
• Guilt
• Criminal participation
• Physical possession
• Who operated a device
• Who entered an author name
• Where a person was physically located
• When the underlying content was written
• Whether a photograph depicts what a caption claims
• Whether an email was personally written by the displayed sender
• Whether a document is complete
• Whether a source obtained a file lawfully
• Whether the contents are true
• Whether an edit was deceptive
• Why a metadata field is missing

A metadata anomaly is not proof of fraud.

---

Common Errors

Treating Metadata as Infallible

Metadata can be edited, stripped, inherited, or generated automatically.

Confusing File Dates with Event Dates

A download date or conversion date does not establish when the underlying event occurred.

Relying on One Tool

Different tools read different metadata layers.

Ignoring Time Zones

A timestamp without a documented zone can create a false timeline.

Modifying the Original

Opening or saving a file may change metadata.

Publishing Sensitive Values

GPS coordinates, usernames, paths, and hidden names can expose survivors, minors, or contributors.

Using Screenshots as Original Evidence

Screenshots usually omit headers, file structure, and provenance.

Overstating Hash Results

A stable hash establishes byte identity, not truth.

Uploading Files to Online Tools

Unapproved online extraction may expose confidential evidence.

Ignoring Missing Metadata

Missing metadata may result from ordinary scanning, conversion, or platform processing.

Hiding Conflicting Results

Tool disagreements and anomalous values must be documented.

---

Step by Step Metadata Workflow

Step 1: Confirm Authorization

Determine whether the file may be lawfully accessed and analyzed.

Step 2: Preserve the Original

Save the received file in an approved preservation location without modification.

Step 3: Create an Intake Record

Record the source, filename, date, evidence ID, restrictions, and relevant EFTA or docket information.

Step 4: Calculate the Initial Hash

Calculate and record a SHA 256 value for the preserved copy.

Step 5: Create a Working Copy

Perform extraction on a separate copy.

Step 6: Record the Tool

Document the tool name, version, settings, extraction date, and time zone.

Step 7: Save Raw Output

Preserve the complete raw extraction output.

Step 8: Review Sensitive Fields

Identify survivor, minor, source, location, account, and device information.

Step 9: Validate Important Results

Repeat the extraction or compare with another trusted tool.

Step 10: Compare External Records

Compare metadata with filing dates, email records, visible content, EFTA information, and other evidence.

Step 11: Classify the Finding

Mark the result as Confirmed, Supported, Suggested, Unknown, Disputed, or Unverified.

Step 12: Write the Limitation

State what the metadata does not prove.

Step 13: Create a Public Extract

Remove protected information without altering the preserved raw output.

Step 14: Complete Editorial Review

Request a second editor for significant, sensitive, or accusatory interpretations.

Step 15: Record Publication

Document the public copy, page address, reviewer, and review date.

---

Key Takeaways

• Preserve the original before opening or extracting metadata.
• Never work on the only copy.
• Record the extraction tool and version.
• Retain raw output.
• Use SHA 256 for important file comparisons.
• A matching hash proves byte identity only.
• Preserve raw timestamps and time zones.
• Treat missing time zones as uncertain.
• Validate important findings with another method.
• Protect survivors, minors, sources, and contributors.
• Do not upload sensitive files to unknown online tools.
• Metadata may support a lead but rarely proves authorship or intent.
• Every published interpretation must include its limitations.

---

Questions

What is metadata?

Metadata is information about a file, message, webpage, record, or digital object.

Is metadata automatically reliable?

No. Metadata can be altered, removed, inherited, copied, or generated by software.

Can metadata prove who wrote a document?

Usually not by itself.

Does an author field identify the author?

It identifies the value stored in that field. The value may come from an account, template, or manual entry.

Does a creation date show when the content was written?

Not necessarily. It may record scanning, conversion, export, or later processing.

Can GPS metadata prove where a person was?

It may support a location lead, but it requires provenance and corroboration.

What does a matching hash prove?

It supports that the compared files contain the same bytes.

Does a matching hash authenticate the contents?

No.

Should contributors use SHA 1?

EpsteinWiki should normally use SHA 256 for current evidence records.

Can metadata be extracted from a screenshot?

The screenshot’s metadata can be extracted, but it does not restore the metadata of the original item shown.

Is an email screenshot equivalent to the original email?

No. It usually lacks complete headers and routing information.

Can the From field authenticate an email?

No. Review complete headers and corroborating evidence.

Should a metadata extract include the tool version?

Yes.

Should raw output be preserved?

Yes.

Can the extraction be performed on the original?

Use a working copy whenever possible.

Can an online metadata viewer be used?

Do not upload sensitive, restricted, or private files to an unapproved service.

What if two tools disagree?

Record the disagreement and investigate the reason.

Should all metadata be published?

No. Publish only information necessary for the evidence analysis.

What if metadata reveals a minor’s identity?

Do not publish it. Apply the Privacy Safeguards for Minors and request review.

What if metadata reveals GPS coordinates for a private residence?

Restrict the information and complete a privacy and safety review.

What if a government file has inconsistent metadata?

Document the inconsistency and consider scanning, OCR, redaction, conversion, and release processing before drawing conclusions.

Can metadata establish criminal involvement?

Not by itself.

Should metadata findings receive an evidence classification?

Yes.

What is the safest wording?

State that the file records a value, then explain the value’s limitations.

---

Related EpsteinWiki Guides

• Evidence Framework
• Handling Contradictory Evidence
• Fact Checking and AI Detection Tools
• Upload Instructions
• Version Control
• Contributor Safety Guide
• Privacy Safeguards for Minors
• Volunteer Conduct Code

---

Sources

• ExifTool Official Documentation
• ExifTool Frequently Asked Questions
• National Institute of Standards and Technology: Secure Hash Standard
• National Institute of Standards and Technology: Hash Functions
• RFC Editor: Internet Message Format
• IPTC Photo Metadata Standard
• Adobe XMP Specifications
• Library of Congress: Digital Preservation
• United States Department of Justice: Epstein Library
• Epstein Data

---

Editorial Note

Metadata can expose valuable evidence, but it can also create false confidence. A timestamp, author field, GPS coordinate, software name, or email header should never be interpreted beyond what the field and surrounding evidence can support.

EpsteinWiki contributors must preserve original files, document every extraction, protect sensitive information, validate important results, and state evidentiary limitations clearly.

Metadata analysis should make the archive more transparent, not more speculative.

Last reviewed: September 6, 2026