How to detect unauthorised changes to an excel file by comparing sha-256 hashes
- Step 1Hash the file at its known-good state — When you are confident the file is correct — right after you finalise it, or right after you receive a trusted copy — drop it into the hasher and record the SHA-256. This is your baseline.
- Step 2Archive the baseline digest — Store the 64-character SHA-256 somewhere the file itself cannot reach: a password manager note, a read-only log, a ticket, or a checksum file (
file.xlsx.sha256). Keeping it separate from the file is what makes later tampering detectable. - Step 3Re-hash whenever you need to verify — Before relying on a copy that has been shared or stored, drop it into the hasher again. There is no options panel — it reads the bytes and computes the digests immediately.
- Step 4Compare the new SHA-256 to your baseline — Paste both strings side by side. Identical = the file is byte-for-byte unchanged. Different = the file was modified; proceed to diagnose.
- Step 5Diagnose a mismatch — First rule out a benign cause: was the file opened and saved (which changes bytes via the Last-Modified XML) without content edits? If you suspect real changes, compare the current copy against a trusted copy with the Range Diff tool to see exactly which cells differ.
- Step 6Re-baseline after legitimate changes — When a change is authorised and accepted, hash the new version and replace the archived digest, with a note on what changed and who approved it. Your baseline should always reflect the current trusted state.
Reading a hash comparison
How to interpret a re-hash against your archived SHA-256 baseline.
| Result | Meaning | Next action |
|---|---|---|
| New SHA-256 == baseline | File is byte-for-byte unchanged | Trust the copy as-is |
| New SHA-256 != baseline, no expected edits | File was modified or re-saved | Diagnose: benign re-save vs real change |
| New SHA-256 != baseline, edits expected | Reflects approved changes | Re-baseline and log the new digest |
| New SHA-256 == empty-input hash (e3b0c442...) | File is zero bytes / failed to read | Re-fetch the file from source |
Benign re-save vs real tampering
A mismatch always means bytes changed — but not always content. Use this to distinguish the two before raising an alarm.
| Symptom | Likely cause | How to confirm |
|---|---|---|
| Hash changed, values look identical | Re-save rewrote Last-Modified XML / ZIP order | Range-diff against a trusted copy → zero value changes |
| Hash changed, a figure differs | Real content edit | Range-diff pinpoints the changed cells |
| Hash changed after a download | App round-trip (e.g. Google Sheets) rewrote the file | Re-download the original source file and re-hash |
| Hash changed after a transfer | ASCII-mode transfer corrupted bytes | Re-transfer in binary mode; re-hash to confirm |
Verification limits by tier
Hashing is byte-only, so only file size matters — never row count. Excel-family limits.
| Tier | Max file size | Files per run |
|---|---|---|
| Free | 5 MB | 1 |
| Pro | 50 MB | 5 |
| Pro + Media | 200 MB | 20 |
| Developer | 500 MB | unlimited |
Cookbook
The archive-and-recheck loop for detecting unauthorised Excel changes. Hashes are illustrative.
Baseline a finalised report
You just signed off a monthly report. Capture its hash so any later change is detectable.
File: Monthly_Close_2026-05.xlsx Baseline SHA-256: fa3416c2c8aef...e91d Stored in: ops-log ticket #4821 (read-only) File shared to Finance via SharePoint.
Re-check before relying on a shared copy
A week later you pull the file back from SharePoint and verify it is the one you signed off.
Re-hash of downloaded copy: fa3416c2c8aef...e91d Baseline: fa3416c2c8aef...e91d Match → nobody altered it. Safe to rely on.
Catch a silent edit
The re-hash doesn't match, and you didn't authorise changes. The hash flags it before the bad number propagates.
Re-hash: 9b74c9897bac...0e21 Baseline: fa3416c2c8aef...e91d Mismatch → the file was changed. Do not trust this copy. Proceed to diagnose what changed.
Tell a re-save apart from a real change
Mismatch found — but is it a harmless re-save or a genuine edit? Range-diff against your trusted copy decides.
Hashes differ, but the numbers look the same. Run /excel-tools/excel-range-diff (trusted copy vs current): → 0 cell differences reported. Conclusion: someone opened and saved the file (new Last-Modified XML) but changed no content. Benign — but re-baseline so future checks compare to the saved bytes.
Re-baseline after an approved edit
A correction was approved. Update the archived digest so the baseline tracks the current trusted state.
Approved change: corrected a tax-rate cell (CR-117). New SHA-256: 1c8f3a55de90...77ab Old baseline retired with note: 'superseded by CR-117'. New baseline logged in ticket #4905.
Edge cases and what actually happens
Hash mismatch with no visible content change
Benign re-saveAn .xlsx rewrites its internal Last-Modified timestamp on every save, so opening and saving with zero edits changes the bytes and the SHA-256. This is the tool correctly reporting a byte change, not a false positive. Confirm with a value-level Range Diff; if it shows no cell changes, the mismatch is a benign re-save.
Mismatch after downloading from cloud storage
ModifiedSome platforms (notably Google Sheets, and occasionally SharePoint's online editor) rewrite an .xlsx when you view or download it, producing a structurally different file. Re-hash the original source file rather than a cloud-round-tripped copy to get a true comparison.
Mismatch caused by a corrupted transfer
Transfer errorAn FTP or sync client in ASCII/text mode can alter bytes inside the ZIP, breaking the hash and silently damaging the .xlsx. Always transfer in binary mode, then re-hash to confirm the bytes survived. A file that no longer opens after transfer is a strong sign of this.
Baseline hash was taken after the file was already modified
Invalid baselineA baseline only proves integrity from the moment it was captured. If you hashed the file after it had already been edited, the baseline endorses the altered state. Capture baselines at a known-good point and keep them in a separate, tamper-resistant location.
File larger than the Free 5 MB cap
Tier limitFree tier rejects files over 5 MB. Row count is irrelevant — only byte size. Use Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB) for larger workbooks.
Comparing two copies on different machines
IdenticalThe same file hashes to the same SHA-256 on any OS. If two machines report different digests for what should be the same file, one copy was modified or corrupted in transit — hash the source-of-truth copy and re-distribute it.
Re-hash matches the empty-input digest
Empty fileIf the SHA-256 is e3b0c442... the file is zero bytes — it failed to download or save. Re-fetch the file; do not treat the empty-input hash as a valid baseline.
Someone changed only the file name, not the contents
IdenticalRenaming or moving a file does not change its bytes, so the SHA-256 is unchanged. The hash verifies contents, not file names — a matching digest after a rename confirms the data is intact.
MD5 used instead of SHA-256 for the comparison
Use SHA-256MD5 has practical collisions, so a matching MD5 is not a reliable integrity guarantee. Compare on SHA-256 (the tool emits MD5 only for legacy compatibility). See why SHA-256 over MD5.
Frequently asked questions
How do I verify an Excel file hasn't been changed?
Hash the file at a known-good state and archive the SHA-256 digest. Later, re-hash the file and compare: an identical digest means the file is byte-for-byte unchanged; any difference means it was modified. Keep the archived digest in a location the file cannot reach so it cannot be altered alongside the file.
The hash changed but I don't see any difference — was the file tampered with?
Not necessarily. An .xlsx rewrites an internal Last-Modified timestamp on every save, so opening and saving with no edits changes the bytes and the hash. To tell a benign re-save from a real change, run a value-level comparison with the Range Diff tool — zero cell differences means it was just a re-save.
Where should I store the baseline hash?
Somewhere separate from the file itself — a read-only log, a ticket, a password-manager note, or a checksum file kept apart from the workbook. The baseline only protects you if an attacker who can edit the file cannot also edit the recorded hash.
Can a colleague verify the file using the same hash?
Yes. The tool hashes raw bytes, so anyone can run shasum -a 256, sha256sum, or Node's crypto.createHash('sha256') on the same file and get the identical digest. Share the baseline and they can confirm the file independently.
Does verification upload my file anywhere?
No. Re-hashing runs in your browser via the Web Crypto API over bytes read locally. Sensitive shared files never leave your device during verification.
Why does downloading from SharePoint or Google Sheets break the match?
Some cloud editors rewrite an .xlsx when you view or download it, producing a different file structure even if the values match. Compare against the original source file, not a cloud-round-tripped copy, to avoid a false mismatch.
What if the re-hash equals e3b0c442...?
That is the SHA-256 of an empty input — the file is zero bytes and failed to download or save. Re-fetch the file from its source; never use the empty-input hash as a baseline.
Does renaming or moving the file change its hash?
No. The hash is over file contents, not the name or path. Renaming or relocating a file leaves the SHA-256 identical — a matching digest after a move confirms the data is intact.
Should I compare on MD5 or SHA-256?
SHA-256. MD5 has practical collisions, so a matching MD5 is not a trustworthy integrity guarantee. The tool emits MD5 only for legacy compatibility — always compare on the SHA-256 digest.
How big a file can I verify on the free tier?
Up to 5 MB per file on Free, one file per run. Row count is irrelevant because hashing is byte-only. Larger workbooks need Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB).
Do I need to set any options before re-hashing?
No. There is no settings panel — drop the file in and Process; it always returns SHA-1, SHA-256, SHA-512, and MD5 over the whole file. There is no algorithm picker.
What is the underlying engine for this check?
This Excel entry point cross-links to the canonical Multi-Hash Fingerprinter, the shared engine that computes all four digests. Both produce the same 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.