Hash a dataroom. Prove nothing changed.
Drop the documents of a dataroom and get each file's SHA-256, a flag on every duplicate, one Merkle root for the whole set, and a check against the manifest you were sent. Files never leave your browser.
Verify the files, then the set.
Every file is hashed with SHA-256[1] by the Web Cryptography API[2] in your browser, and everything runs on your machine. The receipt you download is the only thing that leaves this page, and only because you save it.
Files
Each file is read into memory once[4], hashed, then released. Files over 1 GB are hashed too, with a warning, because the whole file stays in memory while it is hashed.
The receipt is a JSON file with every hash, the duplicate groups, the Merkle root, its construction id and the manifest check. Share it with a counterparty who can re-run this page on the same files.
Set
No files yet. Drop a dataroom to begin.
Each file is hashed with SHA-256. The digests are lowercased, de-duplicated and sorted ascending, so the order in which files are dropped does not change the root and an exact copy of a file counts once. Each sorted digest becomes a leaf, SHA-256(0x00 followed by the 32 digest bytes). Adjacent nodes are paired into SHA-256(0x01 followed by left and right). When a level has an odd count, the last node moves up unchanged. One file gives its leaf hash. No files give no root. For one or more files this equals the RFC 6962 Merkle Tree Hash of the sorted digests.
File hashes
| File | Size | Status | SHA-256 | Copy |
|---|---|---|---|---|
| No files hashed yet. Hashes appear here as each file completes. | ||||
Manifest
Manifest check
Paste or pick a manifest to compare it with the hashed files.
Illustrative verification tool. A matching hash shows that two byte sequences are identical; it says nothing about the content, authenticity or completeness of a document. Nothing here is an offer or financial, investment, legal or tax advice. For qualified counterparties only.
How the root is built, and what the manifest contains.
The construction is deterministic and documented, so anyone with the same files can reproduce the same root without this page. For one or more files the root equals the RFC 6962 Merkle Tree Hash[5] of the sorted, de-duplicated digests. Its identifier, rekord-tools/sha256-sorted-unique-rfc6962-v1, is written into every receipt.
Merkle construction
| Step | Rule |
|---|---|
| 1. Hash | SHA-256 of each file, as dropped, byte for byte. |
| 2. Normalise | Lowercase the hex digests, remove exact duplicates, sort ascending. |
| 3. Leaf | leaf = SHA-256(0x00 ‖ digest bytes), where the digest is the 32 raw bytes, not the hex text. Prefix as in RFC 6962. |
| 4. Pair | node = SHA-256(0x01 ‖ left ‖ right) over adjacent nodes, level by level. Prefix as in RFC 6962. |
| 5. Odd count | The last node on an odd level moves up unchanged. It is not duplicated. |
| 6. Root | One digest gives its leaf hash. No digests give no root (RFC 6962 would give SHA-256 of the empty string). |
The 0x00 and 0x01 prefixes follow RFC 6962[5], which uses this domain separation so a leaf hash cannot be presented as an internal node. Carrying an odd node up unchanged gives the same tree as RFC 6962's split at the largest power of two below the leaf count. Bitcoin's Merkle tree instead duplicates the last node on an odd level, which lets two different transaction lists share a root (CVE-2012-2459)[6][7]. Here, repeated copies of a file are removed before the tree is built, by design.
manifest.json, schema 1.0
| Field | Type | Meaning |
|---|---|---|
schemaVersion | string, required | Must be "1.0". Any other value is rejected with a message. |
algorithm | string, optional | Must be "SHA-256" when present. A missing value reads as SHA-256. |
merkleRoot | string, optional | 64 lowercase hex characters. When present, it is compared with the root computed from the dropped files. |
files | array, required | One entry per document. Matching is by sha256, not by name. |
files[].path | string, required | Path inside the dataroom. Only the last segment (the file name) is used for the name check. |
files[].sha256 | string, required | 64 hex characters, case-insensitive. A Rekord dataroom export names this field fileHash; both names are accepted. |
files[].size | integer, optional | Size in bytes. Informational; not used for matching. |
{
"schemaVersion": "1.0",
"algorithm": "SHA-256",
"merkleRoot": "3f0c…(64 hex characters)",
"files": [
{
"path": "deal/financials-fy2025.pdf",
"sha256": "ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad",
"size": 482113
},
{
"path": "deal/loan-agreement.pdf",
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"size": 0
}
]
}Check categories
| Category | Meaning |
|---|---|
| Matched | Hash and file name both agree with a manifest entry. |
| Renamed | The hash is present, under a different file name. |
| Mismatch | Same file name as a manifest entry, different hash. The bytes changed. |
| Missing | Listed in the manifest, not among the dropped files. |
| Unexpected | Dropped, but not in the manifest. |
A hash checks a file today. An anchor keeps the record.
This page gives you a root for one moment, and nothing is stored. Rekord Kloud hashes each record with SHA-256 and anchors the Merkle root of every version on-chain in an append-only, versioned sequence, so a later change to a record is detectable by anyone holding the original bytes. The Proof Console gives depositors, auditors and regulators read-only access to the same evidence[10]. Rekord Kloud builds its roots with its own documented construction, so the root on this page is not the root Kloud anchors for the same files.
Learn the fundamentals.
Plain-English guides from the Rekord Education Hub on the concepts behind this page.
Frequently asked questions
How do I check the SHA-256 hash of a file?
Drop the file on this page or pick it with the file button. The browser reads the bytes and computes the SHA-256 digest with the Web Cryptography API, then shows the 256-bit digest as 64 hex characters next to the file name. To confirm it against a value you received, compare the two strings, or recompute it on the command line with "shasum -a 256 <file>" or, on Windows, "certutil -hashfile <file> SHA256". The digests must be identical character for character.
Copy linkDo my files get uploaded?
No. Files never leave your browser. The page reads each file into memory, hashes it locally and drops its reference to the bytes. There is no upload endpoint and the page makes no network request that carries file data. You can confirm this in the browser developer tools under Network while you hash a file.
Copy linkWhat is a Merkle root?
A Merkle root is a single hash computed over a list of hashes: each entry is hashed into a leaf, pairs of nodes are hashed together level by level, and the last remaining value is the root. RFC 6962 section 2.1 defines this Merkle Tree Hash over SHA-256. Changing any file, adding one or removing one changes the root, unless two different inputs share a SHA-256 digest, which FIPS 180-4 describes as computationally infeasible. This tool sorts and de-duplicates the file digests first, so the root does not depend on the order in which files were dropped and an exact copy counts once. For one or more files the result equals the RFC 6962 Merkle Tree Hash of the sorted digests; for no files the tool gives no root, where RFC 6962 defines the hash of the empty string.
Copy linkWhy do duplicate files matter in a dataroom?
FIPS 180-4 describes finding two different messages with the same SHA-256 digest as computationally infeasible, so two files with the same digest can be treated as byte-identical, whatever their names. In a dataroom, a duplicate means the same document was supplied more than once, possibly under a different name or folder, so a file count overstates the number of distinct documents. The tool flags every group of files that share a digest.
Copy linkWhat does a manifest mismatch mean?
A mismatch means a file with the same name as a manifest entry is present, but its SHA-256 differs from the one the manifest records. The bytes changed after the manifest was produced: a re-export, an edited PDF, a different version. "Missing" means the manifest lists a hash that no dropped file carries, and "unexpected" means a dropped file is not in the manifest at all. A root mismatch means the set as a whole differs from the one the manifest describes.
Copy linkCan I verify large files?
Yes, within the memory your browser can allocate. The File API arrayBuffer() method reads a whole file into one buffer, and the Web Cryptography API digest() method takes its input as one buffer, so each file is held in memory while it is hashed. The tool hashes files one at a time and warns above 1 GB per file. If the browser cannot allocate the buffer, that file is marked as failed and the rest of the batch continues. For multi-gigabyte files, a command-line tool such as shasum or certutil reads the file from disk instead.
Copy linkSources
The definitions, formulas and figures on this page come from these documents.
- NIST, FIPS 180-4: Secure Hash Standard (SHS) SHA-256 definition, its 256-bit message digest, and why a changed file gives a different digest
- W3C, Web Cryptography API crypto.subtle.digest(), which takes the whole input as one buffer, and the [SecureContext] restriction on crypto.subtle
- W3C, Secure Contexts What a secure context is, and why a page not served over HTTPS has no crypto.subtle
- W3C, File API Blob.arrayBuffer(), which reads a whole file into memory before it is hashed
- IETF, RFC 6962: Certificate Transparency, section 2.1 Merkle Hash Trees Merkle Tree Hash over SHA-256, the 0x00 leaf and 0x01 node prefixes, and the hash of an empty list
- Bitcoin Core v28.0, src/consensus/merkle.cpp The duplicate-last-node rule that lets two different transaction lists share a Merkle root (CVE-2012-2459)
- NIST NVD, CVE-2012-2459 The CVE record for the Bitcoin Core vulnerability named above
- Perl documentation, shasum The shasum -a 256 command-line check
- Microsoft, certutil command reference The certutil -hashfile command-line check on Windows
- Rekord, Rekord Kloud and the Proof Console Per-file SHA-256, append-only versioned anchoring, read-only Proof Console access, and how Kloud builds its own Merkle roots
- Rekord, Rekord AI Source citations with each file's SHA-256, and evidence revision manifests anchored through Rekord Kloud
Other tools
Free, in-browser calculators from Rekord. All tools