Capturing a frame as evidence: timestamps, hashes, and what a still cannot prove

It is worth being specific about the loss, because each item maps to a different kind of claim that becomes unsupportable.

The last row is the one people assume is handled by the file itself, and it is not. A still exported from a browser canvas is a re-encoded image: the pixels are drawn to a canvas and written out as a fresh JPEG or PNG. No EXIF is copied, no source path is embedded, no capture time is written. Whatever the image knows about its origin, you have to write down yourself.

A still with these five fields attached can be checked by someone else. A still without them is an assertion.

1. Source identity — the original filename plus a SHA-256 hash of the file. The filename alone is not enough: two files called recording.mp4 are common, and files get renamed.
2. Media timestamp — the position within the video, to at least a tenth of a second, stated as media time rather than clock time.
3. Extraction method — which tool, which mode, and which output format. “Count mode, 12 frames, PNG, original resolution” is a reproducible statement; “screenshot” is not.
4. Environment — browser and version, operating system, and the source’s codec and resolution. A seek behaves differently across browsers, and a reviewer needs to know which one produced the image.
5. Who and when — the person who captured it and the wall-clock time of capture, in a stated timezone.

Four of the five are one line of text each. The hash is one command:

# macOS and most BSD systems
shasum -a 256 recording.mp4

# Linux, and Windows with Git Bash
sha256sum recording.mp4

Record the full digest. A truncated hash is a hash you cannot verify against a re-computed one, which defeats the purpose. If you need to demonstrate that a file has not changed since a specific date, the hash alone does not do it — you need the hash written into something with a timestamp you do not control, such as a commit, a ticket system, or a signed message.

Every piece of video evidence sits at the intersection of two timelines, and most confused reports come from collapsing them.

• Media time is the position inside the file: 00:01:14.500. It is what a player shows in the scrubber and what an extractor uses. It is only meaningful relative to a specific file.
• Wall-clock time is when the recording was made and when you captured the frame. It comes from the device clock, which may have been wrong, and from the recording metadata, which may have been stripped.

The container often records a creation time, which is the closest thing to a link between the two:

ffprobe -v error -show_entries format_tags=creation_time \
  -of default=noprint_wrappers=1 recording.mp4

Treat that value as a claim rather than a fact. It is written by the recording device, it is often in UTC, it is frequently absent after a transcode, and it can be edited. A report that says “the error occurred at 14:02” without saying whether that is media time or clock time cannot be reconciled with a log that uses the other one — and reconciling a screenshot against an application log is the single most common real task this matters for.

The safe phrasing is explicit: “media time 00:01:14.5 in recording.mp4 (sha256 3f9c…), captured 2026-10-23 14:02:11 +08:00”. Two clocks, two labels, no ambiguity.

Hashing the exported image feels like the rigorous move and is almost useless. The digest of a still proves exactly one thing: that this image file has not changed since you computed the digest. It says nothing about which video it came from, and anyone can produce a different image and hash that instead.

Hashing the source is what creates the link. The chain is: the hash identifies one specific file; the timestamp locates a moment inside it; the mode and format describe how the image was produced. With all four, a second person can re-extract from the same file and get the same frame. Without the hash, they cannot even confirm they have the same file.

One limitation worth stating: a matching hash proves the bytes are identical, not that the bytes are authentic. A re-encoded or edited video will simply have a different hash, and a hash recorded after the fact proves nothing about when the file existed. If authenticity matters, the hash has to be witnessed by a third party at a known time.

When the still will be reviewed by someone who was not there — a client, an auditor, a support escalation, a safety team — the question is not “is this image accurate” but “how would I know”. Write the answer down at capture time, in this order:

1. Where the source file came from: recorded by whom, on what device, and how it reached you. “Screen recording made on the test device during the 14:00 run” is a provenance statement.
2. That the file is the file: the hash, recorded before you did anything else with it.
3. What you did to produce the image: the mode, the timestamp, the format, and whether you cropped or resized it.
4. What you did not do: no retouching, no compositing, no annotation baked into the pixels. If you did annotate, keep the unannotated export alongside it.
5. Where the original is now, and who can access it.

This is not legal procedure; it is the minimum that makes a claim checkable. Most disputes about a screenshot are not about whether the pixels were altered — they are about which of four similar-looking recordings the screenshot came from.

Screen recordings are full of things that should not be forwarded: account names in a corner, an email in a notification, a customer’s address in a form field, an unreleased product in a background window. A still makes all of that permanently legible and easy to paste into a chat.

• Redact before sharing, not after. Once an unredacted still is in a group chat, it is out of your control.
• Record that you redacted, and what you covered. A silently cropped image invites the question of what was removed.
• Keep the unredacted original under the same access control as the source video, not in the downloads folder.
• Crop rather than blur when the redacted region is at the edge; blur is reversible more often than people assume when the underlying text is large and high-contrast.

None of this is specific to frame extraction, but frame extraction is where it happens: the moment you decide a still is worth keeping is the moment it becomes a document that will travel.

There are categories of work where the honest answer is that this workflow is not appropriate, and it is better to say so than to let someone discover it under pressure.

For everything else — a bug report, a design reference, a tutorial step, a thumbnail, a client update — the still is exactly the right instrument, and the five fields turn it from an assertion into a record.

This is the whole artefact. Paste it into the ticket, the report, or the folder’s README, and fill in the blanks.

source_file:      recording.mp4
source_sha256:    3f9c1a…(full 64 hex characters)
source_codec:     h264 High, 1920x1080, 29.97 fps
media_timestamp:  00:01:14.500
extraction_mode:  timestamps
extraction_tool:  Frame Extractor (browser), /en/extract-video-frames-online
output:           PNG, 1920x1080, original resolution
environment:      Chrome 141 / macOS 15.6
captured_by:      name
captured_at:      2026-10-23 14:02:11 +08:00
redactions:       none

Ten lines. It takes less time to write than to argue about afterwards, and it is the difference between a picture and a piece of evidence.