Evidence Basics · 10 min read

Text Message Metadata Explained

What timestamps, sender identifiers, attachments, exports, and hashes can help show, and what they cannot prove alone.

The short answer

Message metadata is everything travelling with a message that is not its text: timestamps, sender and recipient identifiers, thread and conversation IDs, attachment references, delivery and read status, and in some formats a marker for edits. It is genuinely useful and it is routinely overstated. Metadata can establish that a file has not changed since it was hashed, that two messages were fourteen minutes apart, or that a reply referenced an attachment now missing. It cannot establish who was holding a phone, and a timestamp records what a device or platform clock reported rather than an independently verified time. Which fields you get depends entirely on the export: a WhatsApp text export carries a date, a time, and a display name, while a structured export may carry identifiers the text file never had. Note which fields the source actually supplied, and treat anything worked out afterwards as derived. Textimony uses available sender, timestamp, and source fields to support review. It also records an intake checksum for the uploaded file, which supports later byte comparison but does not verify authorship.

Useful metadata fields

Sender and recipient identifiers. Message timestamps and timezone context. Conversation or thread identifiers. Attachment filenames, media references, and missing-media notes. Source file names, upload dates, and artifact hashes. Report settings and generated-output manifests.

How metadata supports review

A timestamp can help place a message in sequence, but it may need device, timezone, export, or provider context. A sender label may reflect a contact name rather than verified identity. A hash can show whether a file changed after hashing, but it cannot prove the message was true. That source context is why preservation and reviewer judgment still matter.

When forensics may be needed

Some matters require professional acquisition from a device, cloud account, or provider record. Textimony organizes the supplied evidence record for review.

Metadata is a review signal, not a magic answer

Text message metadata can include timestamps, sender identifiers, conversation IDs, attachment references, export filenames, device context, phone numbers, emails, account handles, and message order. Those fields help a reviewer understand the record, but they do not automatically prove authenticity or admissibility by themselves. The value comes from consistency. A timestamp pattern that matches the platform, a sender identifier that matches other account records, and a source file that remains available for inspection can support review. Missing or inconsistent metadata should be called out directly instead of hidden behind a clean-looking report.

Metadata fields to preserve

Original filename, export path, platform, export date, and uploader account. Message timestamp, timezone assumption, conversation ID, row number, and message ID when available. Sender display name, phone number, email, account handle, contact alias, and participant-map confidence. Attachment filename, media availability, media omission choice, thumbnail status, and related text. Source hash, working-copy hash, report hash, and generated export filename. Known transformations such as cleanup, redaction, deduplication, timezone normalization, or unsupported fields. Gaps such as deleted-message claims, unavailable media, missing dates, or screenshots without full export context.

How metadata should appear in reports

Reports should expose enough metadata for inspection without burying the reader in raw technical fields. A good evidence window names the sender, timestamp, source file, message ID, context window, issue label, and source note when one exists. Textimony separates metadata from interpretation. A timestamp or sender ID is a source field; a label such as threat, admission, coercion, or contradiction is an analysis layer. Keeping those layers separate makes the output easier to challenge and easier to trust.

Before you share the record

When metadata is uncertain, the report should say so in plain language. A timestamp without timezone context, a sender name copied from local contacts, or a missing attachment reference should remain visible as a source note rather than being smoothed into a confident-looking summary.

Does metadata prove a text message is authentic?

No, though it helps. Metadata can corroborate that a message existed at a stated time in a stated thread, and inconsistencies in it can undermine a claim. But it cannot show who was holding the phone, and metadata in an export is itself only as trustworthy as the export. Authentication rests on the fuller record — testimony, device and account evidence, and content only the sender plausibly knew.

Why do timezone assumptions matter?

Because a timezone error silently reorders events. Shift timestamps by a few hours and a reply can appear to precede the message it answered, a late-night exchange becomes an afternoon one, and a message can move to the wrong calendar day — which matters when a date is the disputed fact. Fix one documented case timezone, apply it consistently, and state the handling in any report that normalizes timestamps.

Can screenshots contain metadata?

Only what is visible in the picture. A screenshot shows whatever timestamp and display name were on screen, which is a rendering rather than the underlying data, and it carries none of the message-level fields an export holds — sender identifiers, precise timestamps, thread and attachment references. The image file has its own metadata about when the capture was taken, which is worth preserving but is a different fact.

What should Textimony do when metadata is missing?

Show the absence rather than filling it. Textimony can only display fields present in the working file, so a missing timezone, sender identifier, or attachment reference stays missing rather than being inferred. The reviewer should record which fields were unavailable and where identity or timing is uncertain, keeping those notes separate from the data itself so an assumption is never read later as a verified fact.

Published by

Textimony. Editorial status: Source-linked informational guide. Updated: 2026-07-10.

Sources

NIST: Guidelines on Mobile Device Forensics; NIST: Digital Evidence Preservation; NIST: Chain of Custody glossary