In discussions of digital evidence, three statements are often treated as equivalent: “I have a screenshot”, “I have a hash” and “I have the evidence”. They are not the same.
The screenshot
It records what was displayed. It can be very useful, especially for ephemeral content or situations that need to be documented quickly. However, it is advisable to retain information about the device, account, date, URL, original file and any source that could corroborate it.
The hash
It is a mathematical fingerprint of the content. It helps verify that a file has not changed between two points in time. It does not establish who created it, whether what it depicts is true, or whether it was obtained lawfully.
The context
It is what makes interpretation possible. A conversation without identified participants, a time zone or provenance can be difficult to place, even if the file is intact.
Two identical files do not tell the whole story
A cryptographic hash is a value calculated from the contents of a file using a particular algorithm. Recalculating it from the same bytes with the same algorithm is expected to produce the same result. This property makes it possible to detect changes to a digital copy and verify that a file delivered now matches one recorded earlier. However, it does not identify the author, does not by itself prove when the content was created, and does not certify that its origin was legitimate. It is a technical integrity control, not a machine for reconstructing facts.
Suppose someone submits a screenshot of a message together with its hash. It may be possible to verify that the file has not changed since that value was calculated, but it remains necessary to investigate whether the screenshot represents a real conversation, which parts were left out, and whether the device was displaying altered information. A perfectly intact image can be misleading from the very moment it is created. File integrity and the reliability of the fact represented must therefore be assessed separately.
Documenting the acquisition procedure
When preserving digital evidence, it is useful to record who made the capture, from which device or service, using which tool and at what time. It should also be noted whether acquisition required access to an account, application of filters, export of messages, or selection of a particular area of the screen. These steps help others understand what the material represents. Documentation does not automatically make evidence admissible or valid, but it reduces uncertainties left open by a screenshot on its own.
A cautious sequence may include preserving the original file, creating a working copy, calculating hashes with suitable algorithms, and recording subsequent operations. Deliberate modifications—such as concealing third-party data in a copy intended for disclosure—should be clearly distinguished from the preserved original. This protects privacy without confusing an edited version with the evidence initially acquired.
Technical context and human context
Metadata may provide information about formats, dates or tools, but they are not infallible either. Some can be changed, lost during export, or reflect the time shown by a misconfigured device. Interpretation should cross-check independent sources where possible: server records, message identifiers, access histories and accounts of the acquisition procedure.
For a junior IT practitioner, the practical lesson is to ask questions before reaching conclusions. What does this file actually allow us to establish? What information is missing? Is there another source that confirms the sequence? How was the copy preserved from the time of extraction? A sound analysis does not need to exaggerate what a hash proves: it becomes more credible precisely when it clearly explains the scope and limits of each technical element.
Why working with verified copies is advisable
When a file may be relevant to an investigation, modifying it during analysis makes it harder to explain what the original contains. One useful practice is to store the material received in a controlled location, calculate a hash, and examine a working copy. If the tool used to view it alters metadata or creates thumbnails, those changes should not be confused with operations performed on the preserved original. The record should state who obtained each version, which tools they used, and when each operation took place. This discipline is accessible to a junior IT practitioner and prevents the analysis itself from introducing avoidable doubts.
An explanation that does not depend on the software used
The names of forensic tools may change, but the questions justifying their use remain: what was obtained, how it was verified, what was modified, and what conclusions the result supports. A report should therefore do more than list software packages or display screenshots of their interfaces. It is preferable to describe the procedure in reproducible terms and identify its limitations. Someone with basic technical knowledge should be able to understand why the preservation was reasonable, even if they need specialist assistance to repeat every operation.
A screenshot submitted as evidence
On receiving an exported conversation, an investigator calculates the file’s hash and preserves a screenshot. Months later, the other party disputes who wrote the message and whether earlier parts of the conversation were omitted.
Comparing hashes helps verify whether the preserved file has changed. The screenshot shows a representation. Attribution and context require other sources, such as the device, account, history and timeline.
Evidence should be presented with its scope made clear. Proving integrity is not the same as proving authorship, the truth of the content, or the lawfulness of its acquisition.