How to hash an excel file with sha-256 for legal and audit integrity
- Step 1Capture the file at the moment of collection — Before anyone opens, sorts, filters, or re-saves the workbook, take a working copy as received. The hash you record now is your baseline — any later handling that re-saves the file will change it. Note the source, custodian, and timestamp in your own log; the tool hashes bytes, it does not stamp them.
- Step 2Drop the file onto the hasher above — Drag the
.xlsx(or any file) into the drop zone. There are no options to configure — this tool has no settings panel; it goes straight from upload to the Process button. The bytes are read locally via the File API; nothing is sent to a server. - Step 3Run the hash — The Web Crypto API computes SHA-1, SHA-256, and SHA-512 in parallel and a small built-in routine computes MD5. For a typical multi-megabyte workbook this resolves in well under a second.
- Step 4Record the SHA-256 digest in your custody log — Copy the 64-character SHA-256 hex string into your evidence register alongside the file name, custodian, and your externally-noted date. SHA-256 is the digest to cite; SHA-512 and SHA-1/MD5 are there for cross-checking against other parties' tooling.
- Step 5Download the JSON report for the file — Save the report (a JSON document listing the digests) next to the evidence file. Store it write-once if you can — the value of a baseline hash is that it predates any dispute about the file's state.
- Step 6Re-hash on demand to prove integrity — When you need to demonstrate the file is unchanged — at deposition, exchange, or audit — drop the same file in again and compare the new SHA-256 to your recorded baseline. Identical strings mean byte-for-byte identical files; any difference means the file was touched. To strip metadata before hashing a sanitised copy, see the Application Metadata Wiper.
What the hasher computes
Every digest is taken over the same raw file bytes in one pass. The tool has no algorithm picker — you always get all four. SHA-1/256/512 use the browser Web Crypto API; MD5 uses a small built-in implementation for legacy compatibility.
| Algorithm | Hex length | Engine | Use in a custody context |
|---|---|---|---|
| SHA-256 | 64 chars | Web Crypto crypto.subtle.digest | The digest to cite — widely accepted, no known collisions, the modern integrity standard |
| SHA-512 | 128 chars | Web Crypto crypto.subtle.digest | Longer digest for higher-assurance contexts; cross-check against other parties' SHA-512 output |
| SHA-1 | 40 chars | Web Crypto crypto.subtle.digest | Legacy interop only — has practical collisions, do not rely on it as the integrity proof |
| MD5 | 32 chars | Built-in JS routine (RFC 1321) | Legacy checklist compatibility only — broken for security; never use as the chain-of-custody hash |
What changes the hash (and what doesn't)
A SHA-256 digest fingerprints bytes, not visible content. These are the actions that do — and do not — alter the digest of an Excel file.
| Action on the file | Hash changes? | Why |
|---|---|---|
| Edit any cell value | Yes | The cell XML inside the .xlsx package changes, so the byte stream changes |
| Re-save with no visible edits | Yes | Excel rewrites the internal Last-Modified timestamp and may reorder/recompress the ZIP entries |
| Open and close without saving | No | If nothing is written back to disk, the bytes are untouched |
| Copy the file to a new folder / rename it | No | The hash is over file contents, not file name or path |
| Recalculate formulas then save | Yes | Cached formula results stored in the XML change, altering the bytes |
| Re-zip the .xlsx with a different tool | Yes (usually) | Different compression level or entry order produces different bytes for the same logical content |
Tier limits for the hasher
The hasher works on the file as a byte stream, so the per-file size cap is the binding limit. Row counts are irrelevant to hashing. Excel-family limits.
| Tier | Max file size | Files per run | Typical evidence fit |
|---|---|---|---|
| Free | 5 MB | 1 | Single contract schedule or audit export |
| Pro | 50 MB | 5 | Large financial models or multi-tab workbooks |
| Pro + Media | 200 MB | 20 | Bulk evidence batches |
| Developer | 500 MB | unlimited | Whole-disclosure-set hashing |
Cookbook
Concrete capture-and-verify scenarios from legal and audit workflows. Hashes shown are illustrative.
Capture a baseline hash at collection
The single most important step: hash the file the instant it is collected, before anyone interacts with it. This digest is what you will compare against later to prove the file is unaltered.
File received from custodian: Q3_Revenue_Schedule.xlsx
Hasher output (JSON report):
{
"sha256": "e3b0c44298fc1c149afbf4c8996fb924...",
"sha512": "cf83e1357eefb8bdf1542850d66d8007...",
"sha1": "da39a3ee5e6b4b0d3255bfef95601890...",
"md5": "d41d8cd98f00b204e9800998ecf8427e"
}
Custody log entry (you record separately):
File: Q3_Revenue_Schedule.xlsx
SHA-256: e3b0c44298fc1c149afbf4c8996fb924...
Custodian: J. Okafor (Finance)
Collected: 2026-06-10 14:22 (your timestamp, not the file's)Verify the file is unchanged before deposition
Months later you re-hash the same file and compare against your recorded baseline. Matching SHA-256 strings are proof of byte-for-byte identity.
Baseline (from custody log): e3b0c44298fc1c149afbf4c8996fb924... Re-hash today: e3b0c44298fc1c149afbf4c8996fb924... Result: IDENTICAL → file is unchanged since collection. If they differ even by one character, the file was modified — investigate before relying on it as evidence.
Reproduce the hash on the command line
Because the tool hashes raw bytes, an independent party can verify your SHA-256 without the tool. This is what makes the digest defensible.
macOS / Linux:
$ shasum -a 256 Q3_Revenue_Schedule.xlsx
e3b0c44298fc1c149afbf4c8996fb924... Q3_Revenue_Schedule.xlsx
Linux (coreutils):
$ sha256sum Q3_Revenue_Schedule.xlsx
Node.js:
crypto.createHash('sha256')
.update(fs.readFileSync('Q3_Revenue_Schedule.xlsx'))
.digest('hex')
All three match the tool's sha256 field exactly.Hash a sanitised copy after wiping metadata
If the original carries author names or paths you cannot disclose, wipe metadata first, then hash the sanitised copy as a separate evidence item — and keep the original's hash on file too.
Step 1: original — hash and log it (sealed copy). ORIGINAL.xlsx sha256: a1b2c3... Step 2: run /excel-tools/excel-app-metadata-wiper → produces SANITISED.xlsx (different bytes, new hash). Step 3: hash the sanitised copy for the production set. SANITISED.xlsx sha256: 9f8e7d... Both hashes are recorded; the wipe step is documented so the byte difference between original and produced copy is explained.
Detect a silent re-save that voids the baseline
A reviewer opened the file 'just to look' and Excel prompted a save on close. The content looks identical but the hash proves it was rewritten.
Baseline: e3b0c44298fc1c149afbf4c8996fb924... After review: 7d865e959b2466918c9863afca942d0f... Digests differ → the file was re-saved. The cell values may be unchanged, but the XLSX package (Last-Modified XML, ZIP order) was rewritten. The reviewed copy is NOT the collected artefact; revert to the sealed baseline copy for evidence.
Edge cases and what actually happens
Re-saving the file changes the hash even with no cell edits
By designAn .xlsx is a ZIP of XML parts, one of which records a Last-Modified timestamp; saving rewrites it and may recompress entries. So opening and saving with zero visible edits still yields a different SHA-256. This is correct behaviour — the hash fingerprints bytes, not visible content. Capture the baseline before any handling and work from a sealed copy.
Two files with identical content but different hashes
ExpectedIf one copy was saved by Excel and another exported by a script, the logical content can match while the ZIP compression and entry order differ, producing different digests. The hash proves byte identity, not content equivalence. To compare logical content, use a value-level diff such as the Range Diff tool instead.
File exceeds the 5 MB Free-tier limit
Tier limitFree tier caps the input at 5 MB per file. A larger evidence workbook is rejected with a tier message. Hashing is byte-only so row count never matters — only file size. Move to Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB) for bigger files.
Hashing a .csv instead of .xlsx
SupportedThe hasher reads raw bytes, so any file type works — CSV, XLSX, ZIP, PDF. For CSV note that the encoding (UTF-8 vs UTF-16, BOM vs no BOM) and line endings (CRLF vs LF) are part of the bytes, so two CSVs that 'look the same' in Excel can hash differently. Hash the exact file you will rely on.
MD5 collision concern raised by opposing party
Use SHA-256MD5 has practical collisions and must never be the integrity proof. The tool emits MD5 only for legacy checklist compatibility. Cite the SHA-256 (or SHA-512) digest as your fingerprint. See the dedicated guide on why SHA-256 over MD5.
No timestamp inside the hash report
By designThe report contains the digests and file size — it does not embed a trusted timestamp, and a hash cannot prove when a file existed on its own. Record the collection date and custodian in your own custody log, or pair the hash with an external timestamping authority / notary if your jurisdiction requires a time anchor.
File opened in Google Sheets then re-downloaded
ModifiedUploading an .xlsx to Google Sheets and exporting it back produces a structurally different file (Google's writer, not Excel's), so the hash changes even if every value matches. Never round-trip an evidence file through another application before hashing the baseline.
Comparing hashes across operating systems
IdenticalThe same file produces the same SHA-256 on Windows, macOS, and Linux — the digest is over bytes, which are OS-independent. A common false alarm is hashing a file that a transfer step (e.g. an FTP client in ASCII mode) silently altered; transfer in binary mode to keep bytes intact.
Empty or zero-byte file dropped in
SupportedA zero-byte file hashes to the well-known empty-input digest (SHA-256 e3b0c442...). If you see that exact value for a file you expected to contain data, the file is empty or failed to read — re-export from the source.
Frequently asked questions
Why does the hash change after I re-save the file with no edits?
Because an .xlsx is a ZIP of XML parts and one part stores a Last-Modified timestamp that Excel rewrites on every save; the ZIP may also be recompressed. The bytes change, so the SHA-256 changes. This is exactly why you must capture the baseline hash before anyone opens and saves the file, and keep working from a sealed copy.
Is SHA-256 acceptable for legal evidence?
SHA-256 is widely accepted in legal and compliance contexts as a file-integrity fingerprint and has no known collisions. It is the algorithm to cite. As always, consult your legal team for jurisdiction-specific admissibility requirements — a hash proves a file is unchanged, not when it existed, so you typically pair it with a documented custody log.
Does my file get uploaded to a server?
No. The hash is computed in your browser with the Web Crypto API (crypto.subtle.digest) over bytes read locally via the File API. A privileged or PII-bearing workbook never leaves your device, so hashing it does not create a disclosure event.
Will the tool's hash match sha256sum or shasum?
Yes, byte-for-byte, as long as you hash the exact same file. The tool, sha256sum file.xlsx, shasum -a 256 file.xlsx, and Node's crypto.createHash('sha256').update(fs.readFileSync(path)) all run SHA-256 over the same raw bytes. The only way to diverge is if the file's bytes differ (e.g. a transfer altered it).
Which of the four hashes should I record?
Record SHA-256 as your primary fingerprint. SHA-512 is a useful longer-digest cross-check. SHA-1 and MD5 are provided only for legacy interoperability — both are broken for security and should never be your integrity proof.
Does the report include a timestamp I can use in a filing?
No. The report lists the digests and file size; it does not embed a trusted timestamp. A hash alone cannot prove when a file existed. Note the collection date in your own custody log, and if you need a verifiable time anchor, pair the hash with a timestamping authority or notary per your jurisdiction's rules.
Can I hash a CSV or other file type, not just XLSX?
Yes — the hasher reads raw bytes, so any file works. For CSV, remember that encoding and line endings are part of the bytes: a UTF-8-with-BOM CSV and a UTF-8-no-BOM CSV that look identical in Excel will hash differently. Always hash the exact file you will rely on.
Are there any options to configure?
No. This tool has no settings panel — it goes straight from upload to Process and always returns SHA-1, SHA-256, SHA-512, and MD5 over the whole file. There is no algorithm picker, no range selection, and no per-sheet hashing.
How big a file can I hash on the free tier?
Up to 5 MB per file on Free, with one file per run. Row count is irrelevant because hashing is byte-only. Larger evidence files need Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB).
If I wipe metadata first, won't that change the hash?
Yes — wiping author names or paths with the Application Metadata Wiper rewrites the file, so the sanitised copy has a different hash than the original. Hash and seal the original, then hash the sanitised copy separately and document the wipe step so the byte difference is explained.
Can two different files ever share a SHA-256 hash?
No collision has ever been found for SHA-256, and finding one is considered computationally infeasible. That is why a matching SHA-256 is treated as proof of byte-for-byte identity. MD5, by contrast, has trivially constructible collisions — never use it for this.
Where does the actual hashing engine live?
This Excel entry point cross-links to the canonical Multi-Hash Fingerprinter, which is the shared engine that computes all four digests for any file. Both produce identical SHA-256 output because both hash the same raw bytes.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.