Screen evidence and authenticity
How to prove a screenshot has not been edited
A screenshot alone cannot prove that it was never edited. A matching cryptographic hash can support a claim that the file has not changed since a trustworthy reference hash was recorded. Establishing what happened before that point requires capture records, source context and, where necessary, independent corroboration.
- Integrity is not truth
- Preserve the original
- Protect the reference hash
What a hash means
Compare bytes against a trusted reference.
A cryptographic hash summarises a file’s bytes. With a suitable algorithm such as SHA-256, matching a trusted reference is strong evidence of byte-for-byte consistency. The reference matters: replacing both the file and an unprotected hash list defeats a simple comparison.
On Windows, PowerShell’s Get-FileHash can calculate SHA-256. Run it on a preserved original, save the algorithm and digest in a controlled record, then calculate it again on the recipient’s copy. Renaming the file does not change its content hash; resaving or recompressing it usually does.
Preservation
Record the context while it is available.
- 01
Keep the first saved file
Preserve it separately from annotated, cropped or redacted working copies. Record which file is the original and who performed the capture.
- 02
Record the method and view
Note the source application or URL, date, time, timezone, visible scope and signed-in state without retaining passwords or tokens. State whether it was a visible-window capture, a browser render or a composite.
- 03
Protect the reference
Record a hash promptly in a controlled audit system or another independently retained record. Restrict changes and preserve access history where available. A digest kept only beside the image is a weak reference.
- 04
Document transformations
Retain separate versions and describe each annotation or redaction. Hash each resulting file when needed; do not expect a changed file to match the original digest.
Limits
A late hash cannot establish an earlier history.
If a file was edited before its first recorded hash, later matching hashes cannot reveal that edit. Recording a digest at capture reduces that undocumented interval, but the capture software, device and recordkeeping process still need to be trusted.
No technical measure establishes that the captured information was true. A genuine capture can show a fabricated webpage, a test account or incomplete context. Corroborate important claims with independent records and explain any gap in the file’s history.
A hash chain can reveal inconsistent changes relative to a trusted reference. It is not automatically an independent timestamp, proof of authorship or proof against a compromised device.
Tool choice
Choose a method that fits the job.
PowerShell and controlled recordkeeping can support basic file checks; specialist preservation processes may be needed for disputes. Bundlepix offers screenshot capture records and an exportable chain of custody, but those records do not turn the displayed information into a proven fact.
Further reading
Sources and reference material
Straight answers
Frequently asked questions
Can image metadata prove a screenshot is original?
Not by itself. Metadata can be changed, removed or copied. Treat it as context to evaluate alongside other records.
Does a matching hash prove the screenshot was never edited?
It supports consistency with the referenced file state, not the history before that state was recorded.
Can I redact a screenshot and keep its original hash?
Keep the original hash for the original file. A redacted derivative needs its own record and usually its own hash because its bytes have changed.