SHA-256 Checksums and Trusted Timestamps: How to Prove a File Has Not Changed

A SHA-256 hash identifies the exact bytes of a file, and a trusted timestamp proves that the hash existed at a given time. Together they show that a file has not changed since that time. Neither shows that the content is true, that the file is authentic, or who created it.

This guide is for finance, claims, legal-operations and compliance teams that keep files as evidence. It shows how to check a SHA-256 hash with tools already on your computer, how to verify an RFC 3161 trusted timestamp, what the rules of evidence say in the EU, the United States and Canada, and how to use both in a review workflow.

What a SHA-256 hash proves and what it does not

A SHA-256 hash is a 256-bit fingerprint of a file, written as 64 hexadecimal characters and calculated from every byte of its content with the algorithm in NIST FIPS 180-4. Unlike a simple checksum such as CRC-32, which only catches accidental corruption, a cryptographic hash is built so that nobody can practically craft a different file with the same value.

A hash is a statement about bytes, not appearance: files with different hashes are different files, even if they look identical on screen.

A mismatch therefore means different bytes, not necessarily a different amount or fraud. A match means the same bytes, not genuine content: anyone can hash a forged invoice, and the value will be perfectly stable. Whoever can change a file can also recompute its hash, so a hash is evidence only when it was recorded where the custodian cannot quietly rewrite it.

SHA-256 is designed so that finding two different inputs with the same hash is computationally infeasible; NIST puts its collision resistance at about 128 bits and SHA-1's at under 80 bits (NIST hash functions). NIST plans to transition away from SHA-1 for all applications by December 31, 2030 (NIST announcement), and MD5 is no longer acceptable where collision resistance is required (RFC 6151). Use SHA-256 or stronger for evidence.

How to check a SHA-256 checksum on Windows, macOS and Linux

To check a SHA-256 checksum, compute the hash of the file on your own computer and compare the whole result with the expected value.

Then compare:

1. Hash the file itself, not a copy that was opened and saved in an application.
2. Compare every character with the expected value. Hexadecimal is case-insensitive: PowerShell prints capitals and sha256sum prints lowercase, and both are the same value.
3. Treat anything other than a complete match as a different file. Checking only the first and last characters is not enough.

To test your tool, hash a file that contains exactly the three characters abc (printf abc > test.txt on macOS and Linux, Set-Content -Path test.txt -Value abc -NoNewline in PowerShell). The result must be ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. If a text editor adds a final line break, it becomes edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb: one invisible byte changes the hash.

To verify a published checksum file named SHA256SUMS, run sha256sum -c SHA256SUMS on Linux or shasum -a 256 -c SHA256SUMS on macOS; each listed file is reported as OK or FAILED. In PowerShell, (Get-FileHash .\invoice.pdf).Hash -eq 'EXPECTED_HASH' returns True or False without regard to case.

Where the expected value comes from matters. A checksum published beside a file protects against a damaged download, not against someone who can alter both. For evidence, take it from an independent record such as your intake log or a trusted timestamp.

Be careful with online file hash checkers. Many require you to upload the file, which gives a third party its full content, and you cannot easily tell whether a page hashes in your browser or on its server. For confidential material such as claim evidence, contracts or identity documents, use the local commands above.

What a trusted timestamp adds: the RFC 3161 flow

A trusted timestamp is a signed statement from an independent time-stamping authority (TSA) that a particular hash existed at a particular time, as defined in RFC 3161. File dates and metadata are not trusted timestamps: the “date modified”, a PDF's creation date and a photo's capture date are written by software on a device you may not control, and they can be edited. A trusted timestamp comes from a third party whose clock and signing key are separate from yours.

The flow has four steps:

1. You compute the SHA-256 hash of the file.
2. You send the hash, not the file, to the TSA in a timestamp request, usually with a random nonce to detect replays.
3. The TSA signs a token that binds your hash to the time at which it creates the token, in UTC, with a serial number and its policy.
4. The TSA returns the token, and you store it beside the file.

The TSA never sees the file, which is why timestamping works for confidential material. To verify, recompute the file's hash, confirm that it matches the hash inside the token, check the TSA's signature and confirm that its certificate chains to a root you trust and was issued for time stamping. OpenSSL does all of this (OpenSSL documentation):

The request goes to the TSA's endpoint as an HTTP POST with the content type application/timestamp-query. The -text output shows the hash, the serial number and the time in GMT. A successful verify prints Verification: OK; if the file differs from the one that was stamped, it prints Verification: FAILED with a “message imprint mismatch” error. The file chain.pem holds the TSA's root certificate, -untrusted supplies missing intermediates, and -token_in verifies a bare token instead of a response.

TSA certificates expire and keys can be compromised. A token can remain meaningful after its certificate expires, provided the certificate was valid when the token was issued and the key was not compromised, but a naive check years later can fail; -attime validates the chain as of the token's time. Records kept for years should capture revocation information and be re-timestamped with archive timestamps or evidence records (RFC 4998).

A PDF can also carry the token inside the file as a document timestamp, defined in the PAdES profile of ETSI EN 319 142-1. It covers every byte of the PDF up to the moment it was added; later edits are not covered. Acrobat lists document timestamps with the signatures in its Signatures panel; open the properties to read the time, the issuer and the validation status.

Legal weight of hashes and trusted timestamps in the EU, US and Canada

Hashes and trusted timestamps carry legal weight as evidence, but how much depends on the jurisdiction, the proceeding and the facts. This section is general information as of November 2, 2026, based on the primary texts linked below, and not legal advice; involve counsel before relying on it in a dispute.

European Union

Regulation (EU) No 910/2014 (eIDAS) defines an electronic time stamp as data that binds other data to a particular time, establishing evidence that the latter existed at that time. Under Article 41(1), it cannot be denied legal effect and admissibility as evidence solely because it is electronic or not qualified. Under Article 41(2), a qualified electronic time stamp enjoys the presumption of the accuracy of the date and time it indicates and the integrity of the data to which they are bound.

Article 42(1) requires a qualified time stamp to bind date and time to data so as to reasonably preclude undetected change, to rely on an accurate time source linked to UTC and to be signed or sealed by a qualified trust service provider or an equivalent method. Regulation (EU) 2024/1183 amended Article 42 and added Article 24a(6), which requires recognition of a qualified time stamp from one Member State in all others, and Implementing Regulation (EU) 2025/1929 sets ETSI EN 319 421 and EN 319 422 as reference standards (consolidated eIDAS, Regulation 2024/1183, Implementing Regulation 2025/1929). An ordinary RFC 3161 timestamp therefore cannot be rejected merely for lacking qualified status, but only a qualified one carries the statutory presumption; check a provider's status in the eIDAS Dashboard.

United States

The Federal Rules of Evidence do not single out timestamps. Under Rule 901(a), the proponent must produce evidence sufficient to support a finding that an item is what it is claimed to be, and Rule 901(b)(9) allows evidence describing a process or system and showing that it produces an accurate result (Rule 901). Rule 902(14), added in 2017, lets a party self-authenticate data copied from an electronic device, storage medium or file if it is authenticated by a process of digital identification, shown by a certification of a qualified person; the Advisory Committee note identifies hash value as the ordinary method. Rule 902(13) does the same for a record generated by an electronic process or system that produces an accurate result. Both require a certification and written notice to the adverse party before trial (Rule 902). Authentication is only a threshold, and state courts apply their own rules.

Canada

The Canada Evidence Act applies to proceedings within federal jurisdiction; provincial courts apply provincial evidence statutes, which commonly contain comparable rules (Canada Evidence Act). Section 31.1 puts the burden on the party offering an electronic document to prove its authenticity. Under section 31.2(1), the best evidence rule is satisfied on proof of the integrity of the electronic documents system in which the document was recorded or stored, and section 31.3 lists how that integrity can be shown absent contrary evidence. Sections 31.5 and 31.6 allow evidence of standards and practice, by affidavit. The Act does not mention hashes or timestamps; a recorded hash and a third-party timestamp are practical evidence of a documented practice.

Using hashes and timestamps in a review workflow

A hash and a timestamp only help if they are captured at the right moment and kept apart from the file:

1. Hash at intake, before anyone opens, renames, annotates or re-saves the file. Work on copies.
2. Record the hash in the case record with the file name, source, channel, time received and receiver.
3. Store the original read-only, where changes are logged.
4. Timestamp a manifest, a text file listing each file name with its hash, so one token dates every file on the list.
5. Compare on resubmission. A different hash means a new version to review from scratch, whatever the file name says.
6. Keep a verification kit of file, hash record, token, certificate chain and commands, so someone else can repeat the check years later.

The hash tells you whether a file is the one you recorded. The PDF edit-checking guide explains how to examine what changed inside it, and the invoice verification guide shows how to match it against purchase and payment records. Signed provenance metadata, covered in the guide to C2PA, AI watermarks and image detectors, is a different mechanism: it records how an asset was made, while a hash and timestamp only fix its bytes in time.

How Fileverity reports use SHA-256 and RFC 3161

Each Fileverity report records the SHA-256 hash of the file it examined, so a later reviewer can confirm which file the findings refer to. At issue, the report data, which records that hash, is timestamped by DigiCert's RFC 3161 time-stamping authority. The Trust & security page describes how reports are sealed and verified. PDF reports also carry a PAdES document timestamp that chains to a root in Adobe's Approved Trust List.

A timestamp or seal is indicated only when validation succeeds. If the service or the validation material is unavailable, the report is still delivered, with that proof explicitly marked absent. Fileverity describes these as RFC 3161 trusted timestamps, not as qualified electronic time stamps. The verify page shows the results recorded at issue and matches an image or the report's data file on your own device.

A timestamp establishes that data existed at a time, not that document facts or findings are correct. Fileverity does not keep your original as a long-term archive, so keep your own copy; the recorded hash lets you show later that it is the one that was examined. Document analysis covers what a hash cannot: text, file structure, recoverable saved revisions and supported PDF signature validation.

Worked example: two invoice PDFs and one disputed amount

This case is fictional, and hash values are shortened. On March 3, an accounts payable clerk receives invoice INV-2207 as a PDF attachment. Before opening it, she saves it unchanged and computes its SHA-256 hash, which begins 9f3c1a. She logs the hash, sender, email message ID and time received, then writes a one-line manifest, timestamps it and stores the token. The invoice shows USD 12,048.00 and is approved.

Six weeks later, the supplier says the invoice was for USD 12,480.00 and sends “the same PDF”. Its hash begins 41d7b2. The clerk proceeds as follows:

1. Different hashes mean different bytes. They do not say what differs or who changed it.
2. She runs openssl ts -verify -data intake-manifest.txt -in intake.tsr -CAfile chain.pem, then finds the hash of her stored original in the manifest. The token's time is March 3.
3. She compares the two PDFs, as in the PDF edit-checking guide, and asks the supplier through its onboarding contact for a copy from its invoicing system.

The evidence supports a narrow conclusion. The buyer's copy existed unchanged on March 3, and the supplier's PDF is a different file. Who altered which file is not established, and the email record, not the timestamp, shows what the supplier sent. The amount owed is decided from the purchase order, receiving records and contract, as in the invoice verification guide.

Common questions

Is SHA-256 still secure?

Yes, for integrity and evidence uses. NIST's policy allows federal agencies to use SHA-2, which includes SHA-256, for all applications that employ secure hash algorithms (NIST policy). MD5 and SHA-1 are the functions to avoid. For records kept many years, plan to re-timestamp as algorithms and certificates age.

Can two different files have the same SHA-256 hash?

Mathematically yes, because there are far more possible files than 256-bit values. SHA-256 is designed so that finding such a pair is computationally infeasible, which the roughly 128-bit collision-resistance estimate expresses. A matching hash is therefore strong practical evidence of identical bytes, not a mathematical proof.

Does a trusted timestamp prove who created a file?

No. A timestamp binds a hash to a time and nothing else. It does not identify the author, show that the content is true or show that the file was not created moments before it was stamped. Authorship needs other evidence, such as a digital signature or the sender's own records.

Does renaming or copying a file change its hash?

No. The hash is calculated from the content only, so renaming, moving or copying gives the same value. Saving the file again in an application usually changes it, even when nothing looks different.

Is it safe to use an online SHA-256 checker?

Only for files you could publish. Many online checkers upload the file, so the operator receives its full content. For confidential files, use Get-FileHash, certutil, shasum or sha256sum on your own computer; the result is the same and nothing leaves the device.

By Yang Zheng · Reviewed by Bill Liu