How to generate a sha-256 hash of an excel contract schedule for legal proceedings
- Step 1Seal the schedule as received — Before counsel, paralegals, or experts open the workbook, keep a working copy exactly as it arrived. The hash you take now is the fingerprint you will defend — any later save rewrites the file's bytes.
- Step 2Drop the schedule into the hasher — Drag the
.xlsxinto the drop zone above. There is no options panel — the tool reads the bytes locally and goes straight to Process. The schedule is never transmitted anywhere. - Step 3Compute the fingerprint — Web Crypto computes SHA-1, SHA-256, and SHA-512 over the bytes; a built-in routine adds MD5. A multi-tab pricing annex resolves in under a second.
- Step 4Enter the SHA-256 in your custody record — Copy the 64-character SHA-256 into your evidence log next to the file name, the custodian, the source (email, data room, signed PDF attachment), and your externally-noted collection date.
- Step 5Download and store the report write-once — Save the JSON hash report alongside the sealed schedule. Storing it write-once (or committing it to a system with its own audit trail) reinforces that the fingerprint predates any dispute.
- Step 6Re-hash to prove integrity at exchange or hearing — When you produce the schedule or testify to its integrity, re-hash the file and compare to your baseline. A match proves byte-for-byte identity. If a counterparty produced their own copy, compare digests — a mismatch flags a divergent version and you can value-diff it with the Range Diff tool.
Digests produced for a contract schedule
All four are computed over the same raw bytes in a single pass; there is no algorithm picker. SHA-1/256/512 via Web Crypto; MD5 via a small built-in routine.
| Algorithm | Hex length | Role in evidence | Cite as proof? |
|---|---|---|---|
| SHA-256 | 64 chars | Primary fingerprint of the schedule | Yes |
| SHA-512 | 128 chars | Higher-assurance cross-check | Yes |
| SHA-1 | 40 chars | Legacy interop only | No (practical collisions) |
| MD5 | 32 chars | Legacy checklist compatibility | No (broken) |
Events that break a contract-schedule fingerprint
Each of these rewrites the .xlsx bytes, so the SHA-256 will differ from your sealed baseline. Document any deliberate transformation so the byte change is explained.
| Event | Hash changes? | Custody implication |
|---|---|---|
| A reviewer edits a value in the schedule | Yes | The produced copy is no longer the collected artefact — revert to the sealed baseline |
| File opened and saved on close (no edits) | Yes | Excel rewrote the Last-Modified XML; use the sealed copy, not the reviewed one |
| Schedule re-exported from another app (Sheets, LibreOffice) | Yes | A different writer produces different bytes even with identical values |
| File copied, renamed, or moved | No | Name and path are not part of the hash |
| Metadata wiped before production | Yes | Expected — hash and document the sanitised copy separately |
| Transferred over a network in binary mode | No | Bytes preserved; ASCII-mode transfers can corrupt and must be avoided |
Cookbook
Capture-and-prove patterns for contract schedules in dispute and diligence work. Hashes are illustrative.
Fingerprint the schedule attached to a signed agreement
The executed contract referenced Schedule 3 (the payment timetable) as a separate .xlsx. Hash it at signing so its state is fixed alongside the agreement.
File: Schedule3_Payment_Timetable.xlsx
Report:
{
"sha256": "2c26b46b68ffc68ff99b453c1d304134...",
"sha512": "3bafbf08882a2d10133093a1b8433f50...",
"sha1": "19fc8b6e85bb6e5f7f8e0c4a...",
"md5": "5d41402abc4b2a76b9719d911017c592"
}
Log: bind sha256 to the contract's execution date and store
the sealed file + report with the agreement bundle.Prove the produced schedule equals the collected one
At document exchange, demonstrate the schedule you produce is byte-identical to what you collected.
Collected baseline: 2c26b46b68ffc68ff99b453c1d304134... Produced copy hash: 2c26b46b68ffc68ff99b453c1d304134... Match → the production set contains the original artefact, unmodified. Recorded in the production index.
Detect a counterparty's altered schedule
The other side produced 'the same' Schedule 3. Compare hashes to see if it really is.
Your sealed copy: 2c26b46b68ffc68ff99b453c1d304134... Theirs (produced): 486ea46224d1bb4fb680f34f7c9ad96a... Digests differ → not the same file. Run a value-level diff (/excel-tools/excel-range-diff) to pinpoint which figures or rows changed between the two versions.
Independent expert reproduces your hash
Defensibility comes from the other side being able to confirm your fingerprint without your tool.
Your filing states: sha256 = 2c26b46b68ffc68ff99b453c1d304134... Their expert runs: $ shasum -a 256 Schedule3_Payment_Timetable.xlsx 2c26b46b68ffc68ff99b453c1d304134... Schedule3...xlsx Identical → your fingerprint is verified independently.
Hash a redacted schedule for production
The schedule contains pricing you must redact before production. Wipe document properties, then hash the redacted copy as its own evidence item.
Original (sealed): sha256 = 2c26b46b... Run /excel-tools/excel-app-metadata-wiper to strip author + path metadata → REDACTED_Schedule3.xlsx (new bytes). Redacted copy hash: sha256 = c1d3f0a2... Both hashes logged; the wipe step documented so the byte difference between sealed and produced copy is accounted for.
Edge cases and what actually happens
Schedule re-saved by a reviewer voids the baseline
ModifiedIf anyone opens the workbook and Excel writes it back on close, the Last-Modified XML and ZIP layout change, so the SHA-256 differs from your sealed baseline. The reviewed copy is no longer the collected artefact. Always work from a sealed copy and re-distribute that, never the reviewed file.
Identical figures, different hash
ExpectedTwo schedules can show the same numbers yet hash differently if one was saved by Excel and the other exported by a script or another app — compression and entry order differ. The hash proves byte identity, not value equivalence. For value comparison use the Range Diff tool.
No embedded timestamp in the report
By designThe report lists digests and file size but does not stamp a time. A hash proves the file is unchanged, not when it existed. Anchor the date in your custody log, or pair the digest with a timestamping authority / notarisation if the matter requires a verifiable time point.
Schedule larger than 5 MB on Free tier
Tier limitFree caps input at 5 MB per file. A heavily-formatted annex with embedded objects can exceed that. Row count is irrelevant — only byte size. Move to Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB).
MD5 cited by the other side as the hash
Use SHA-256MD5 has trivially constructible collisions and must never be the integrity proof for evidence. The tool emits MD5 only for legacy checklists. Insist on SHA-256 (or SHA-512). The SHA-256 vs MD5 guide lays out the argument.
Workbook round-tripped through Google Sheets
ModifiedUploading the .xlsx to Sheets and re-downloading produces a Google-written file, structurally different from Excel's output, so the hash changes even if values match. Never round-trip an evidence schedule through another application before sealing the baseline.
Macro-enabled .xlsm schedule
SupportedThe hasher reads raw bytes, so .xlsm hashes fine. Note that the embedded VBA project is part of the bytes — if you strip macros for production with the VBA Macro Stripper, the sanitised copy gets a new hash; record both.
Two custodians produce the same schedule from the same email
IdenticalIf both saved the identical attachment to disk without opening it, both copies hash the same SHA-256 — confirming a single shared artefact. A divergence usually means one custodian opened and re-saved it; treat the unopened copy as authoritative.
File transferred in ASCII/text mode
Transfer errorAn FTP or sync client in text mode can alter line-ending bytes inside the package, changing the hash and silently corrupting the .xlsx. Always transfer evidence files in binary mode and re-hash after transfer to confirm bytes survived intact.
Frequently asked questions
How does a SHA-256 hash prove a contract schedule wasn't altered?
The hash is a deterministic fingerprint of the file's exact bytes. If the schedule is changed in any way — a figure, a row, even a trailing space — re-hashing produces a different SHA-256. So a digest that still matches your sealed baseline proves the file is byte-for-byte identical to the collected version.
Can opposing counsel verify my hash independently?
Yes, and that is the point. Because the tool hashes raw bytes, anyone can run shasum -a 256 (macOS), sha256sum (Linux), or Node's crypto.createHash('sha256') on the same file and get the identical digest. The fingerprint is reproducible, not something only your tool can produce.
Does the report include a date I can put in a filing?
No. The report contains the digests and file size only — there is no embedded timestamp, and a hash on its own cannot prove when a file existed. Record the collection date in your custody log, and use an external timestamping authority or notary if the matter needs a verifiable time anchor.
Why does the hash change if I just open and save the schedule?
An .xlsx is a ZIP of XML parts; saving rewrites an internal Last-Modified timestamp and can recompress the package. The bytes change, so the SHA-256 changes — even with no value edits. This is why you seal a baseline copy before anyone opens the workbook.
Is my confidential schedule uploaded anywhere?
No. Hashing runs in your browser via the Web Crypto API over bytes read locally. A privileged or commercially sensitive schedule never leaves your device, so fingerprinting it does not create a disclosure event.
Which digest should I cite in my filing?
Cite SHA-256 as the fingerprint; SHA-512 is a stronger cross-check if needed. Do not cite SHA-1 or MD5 as integrity proofs — both have practical collisions and are provided only for legacy interoperability.
What if the counterparty's 'same' schedule has a different hash?
Different digests mean different files at the byte level — they are not the same artefact. Run a value-level comparison with the Range Diff tool to find exactly which cells, rows, or figures changed between the two versions.
Can I hash a macro-enabled .xlsm or a CSV schedule?
Yes — the hasher reads raw bytes, so any file type works, including .xlsm and .csv. Be aware that for .xlsm the VBA project is part of the bytes, and for .csv the encoding and line endings are part of the bytes; hash the exact file you will rely on.
Do I need to configure anything before hashing?
No. There is no settings panel — the tool 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 or per-sheet option.
How large a schedule can I hash for free?
Up to 5 MB per file on the Free tier, one file per run. Row count does not matter because hashing is byte-only. Larger annexed workbooks need Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB).
If I redact the schedule before producing it, will the hash change?
Yes. Any edit, including redaction or wiping document properties with the Application Metadata Wiper, rewrites the file and changes the hash. Hash and seal the original, then hash the redacted production copy separately and document the redaction so the byte difference is explained.
Where is the real hashing engine?
This Excel entry point cross-links to the canonical Multi-Hash Fingerprinter, the shared engine that computes all four digests for any file. Both return the identical SHA-256 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.