Research files · Preservation practice

Has your research file changed? Check the original with SHA-256

You saved a document on Monday. On Friday, a colleague sends back a copy with a tidier filename. It looks the same. Before citing it, you want to answer a small but important question: is this still the file you preserved?

A SHA-256 file hash is useful for that comparison. It is a digest calculated from the file’s bytes. Keep a reliable baseline and compare a later calculation with it. The result helps check byte integrity; it cannot tell you whether the document’s story is true.

Preserve first, calculate second, work on a copy

For a file you are entitled to hold, create a simple folder arrangement: an original, a working copy and a record of how you obtained it. Save the source URL or supplied-file context and the collection time with a time zone. Calculate the original’s hash before converting, redacting or extracting text.

Keep the reference digest somewhere it will not be casually overwritten alongside the working file. A separate, versioned record is useful. If someone can replace both the file and its only baseline, a later match to that baseline provides little reassurance. This workflow is not a tamper-proof evidence system or a legal certification.

Give derived files new names. For example, notice-original.pdf, notice-ocr.txt and notice-redacted.pdf have different roles. Expect their bytes and hashes to differ. The task is to keep their relationship clear, not make every hash match.

Calculate a file hash locally in PowerShell

Microsoft’s Get-FileHash command calculates a digest from file contents. This example explicitly selects SHA-256 and uses a literal path, so wildcard characters are not treated as a search pattern:

Get-FileHash -LiteralPath 'C:\Research\notice-original.pdf' -Algorithm SHA256

Replace the example path with your file’s path. Read the Algorithm, Hash and Path fields. Compare the complete hash, not a few matching characters. There is no need to upload the research file to an online calculator.

Hashing a file is different from copying its visible text into a text-hash tool. The file may contain formatting, metadata or other bytes that are absent from the pasted text. Our free tools exercise demonstrates a text fingerprint; this workflow preserves and compares the actual file.

A four-file experiment we ran

On 12 October 2026, we created four small UTF-8 text files without a byte-order mark and compared Python SHA-256 output with PowerShell Get-FileHash. Both methods returned the same digest for each file. These are deliberately constructed teaching fixtures, not recovered evidence or an OSINT Jet product benchmark.

The original contains two lines, Harbour note and status=pending, with an LF newline after each line. We made one byte-for-byte copy with a different name, one version using CRLF newlines, and one LF version changing pending to confirmed.

The baseline digest was:

541cf99519c85610355bdb7863b0192f688fefeab16afc645a4da3ec90a64004

Want to reproduce the exact bytes? In a new empty exercise folder, run this Python snippet, then run the PowerShell command on each file. The script writes only the four named practice files in the current folder.

from pathlib import Path
original = b"Harbour note\nstatus=pending\n"
files = {
    "original.txt": original,
    "renamed-copy.txt": original,
    "windows-lines.txt": b"Harbour note\r\nstatus=pending\r\n",
    "changed-status.txt": b"Harbour note\nstatus=confirmed\n",
}
for name, data in files.items():
    Path(name).write_bytes(data)

The renamed file demonstrates that a filename is not the file’s content. The newline example is the more useful surprise: two files can look identical in an editor while containing different bytes. The changed-status example shows the reverse limitation. A digest flags a difference but does not explain whether it was harmless formatting or a meaningful edit. You need a comparison of the contents for that.

Record the comparison, not just the long number

A useful integrity log has a row for the original and another for each derived file. Include the source or acquisition context, collection time, filename, role, byte length, algorithm and full digest. For a transformation, record the parent file, action, tool and time. For a later check, add the time, digest and comparison result without replacing the old row.

Example note: “The colleague’s renamed copy matched the preserved original’s SHA-256. The text file produced by OCR is a derivative and has its own digest. The match does not verify the document’s author or factual claims.”

For OCR specifically, keep the page image available so that important extracted words can be checked against it. The PDF OCR verification guide addresses that reading problem. Hashes help distinguish the files; they do not correct recognition errors.

What to do when the digest does not match

1. Check that you selected the right file and algorithm.
2. Keep both versions. Do not overwrite the baseline while investigating.
3. Look for documented transformations: conversion, redaction, metadata edits, encoding or newline changes.
4. Compare the contents and record the explanation you can actually support.

A newly downloaded file from the same URL may be a newer or regenerated version. A different digest does not prove malicious tampering. If you never kept the earlier file or its reliable baseline, calculating a hash now cannot reconstruct that missing history.

SHA-256 is designed to make accidental matching between different contents extraordinarily unlikely in practical use, but a matching digest is not a digital signature, a trusted timestamp or evidence that a claim is accurate. Source evaluation remains a separate part of the investigation.

Carry the file history into the report

Before sharing a research conclusion, make it clear which preserved file supports each observation and which copies were transformed. The OSINT Jet report worksheet gives you a structure for those source notes. A file-integrity check can be completed locally; you do not need a paid investigation merely to calculate a digest.

Sources

Command behaviour was checked against Microsoft’s Get-FileHash documentation. The US National Archives also describes checksum verification after transfer and during storage in its video-preservation workflow; that is a preservation example, not a claim that this small exercise meets an institutional or legal standard.