How to hash excel files with sha-256 instead of md5 — here's why it matters
- Step 1Drop the Excel file into the hasher — Drag the
.xlsx(or any file) into the drop zone. There is no algorithm picker and no options panel — the tool always returns all four digests, so you don't choose between MD5 and SHA-256, you get both. - Step 2Run the hash — Web Crypto computes SHA-1, SHA-256, and SHA-512 over the bytes in parallel; the built-in routine adds MD5. Results appear in well under a second.
- Step 3Read both digests from the report — The report lists
sha256(64 hex chars) andmd5(32 hex chars) over the identical byte stream, alongsidesha1andsha512. - Step 4Use SHA-256 as your integrity record — Store the SHA-256 as the authoritative fingerprint in your evidence log, security baseline, or manifest. This is the value you compare against in future integrity checks.
- Step 5Hand MD5 only to systems that demand it — If a legacy intake form or older audit tool requires an MD5 checksum field, supply the
md5value to satisfy it — but never treat that MD5 match as your integrity guarantee. - Step 6Standardise new workflows on SHA-256 — For any new process, drop MD5 entirely and record SHA-256 (or SHA-512 for higher assurance). To embed the digest in a build or CI manifest, the same SHA-256 is available from the canonical Multi-Hash Fingerprinter and from Node's
crypto.createHash('sha256').
SHA-256 vs MD5 (and the rest) for Excel integrity
All four are produced over the same bytes by this tool. 'Collision resistance' is the property that decides whether a digest can be trusted as an integrity proof.
| Algorithm | Hex length | Collision resistance | Safe as integrity proof? |
|---|---|---|---|
| SHA-256 | 64 chars | No known collisions | Yes — recommended default |
| SHA-512 | 128 chars | No known collisions | Yes — higher assurance, longer digest |
| SHA-1 | 40 chars | Practical collisions demonstrated (2017) | No — legacy interop only |
| MD5 | 32 chars | Trivially constructible collisions | No — legacy checklist compatibility only |
When each digest is appropriate
Choosing the right field from the report for the job. The tool gives you all four; you decide which to record.
| Scenario | Use | Reason |
|---|---|---|
| Legal chain of custody | SHA-256 | No collisions; widely accepted as evidence |
| SOC 2 / regulatory baseline | SHA-256 | Standards-aligned, defensible |
| Build / SRI / content addressing | SHA-256 | What the standards are defined on |
| Higher-assurance archival | SHA-512 | Longer digest, same collision resistance |
| Legacy intake form requiring MD5 | MD5 (supplied) + SHA-256 (recorded) | Satisfy the field without trusting MD5 |
| Casual non-security checksum | Any (prefer SHA-256) | Even here SHA-256 costs nothing extra |
Cookbook
Side-by-side digests and the right way to use each. Hashes are illustrative.
One file, all four digests at once
The tool never makes you choose — a single run returns every algorithm over the same bytes.
File: Audit_Evidence.xlsx
{
"sha256": "9f86d081884c7d659a2feaa0c55ad015...",
"sha512": "ee26b0dd4af7e749aa1a8ee3c10ae992...",
"sha1": "0a0a9f2a6772942557ab5355d76af442...",
"md5": "098f6bcd4621d373cade4e832627b4f6"
}
Record sha256 as the integrity fingerprint; md5 is there
only if a legacy system asks for it.Why an MD5 match can lie
MD5 collisions are constructible, so two different files can share an MD5 — meaning a match does not prove the file is the original.
FileA.xlsx md5: 79054025255fb1a26e4bc422aef54eb4 FileB.xlsx md5: 79054025255fb1a26e4bc422aef54eb4 (different file!) Same MD5, different content → an attacker could substitute FileB and an MD5-only check would pass. SHA-256 of the two files differs → SHA-256 catches it.
Satisfy a legacy MD5 field, record SHA-256
An older audit portal has only an MD5 column. Supply MD5 there, but keep SHA-256 as your real record.
Legacy portal field 'File checksum (MD5)': 098f6bcd4621d373cade4e832627b4f6 Your internal evidence log: sha256 = 9f86d081884c7d659a2feaa0c55ad015... (the value you actually verify against later)
Reproduce SHA-256 in CI to drop MD5
Modernise a pipeline by computing SHA-256 in Node — identical to the tool's output, so you can retire MD5 checks.
Node prebuild:
crypto.createHash('sha256')
.update(fs.readFileSync('Audit_Evidence.xlsx'))
.digest('hex')
// → 9f86d081884c7d659a2feaa0c55ad015...
Same bytes in, same SHA-256 out as the browser tool.
Diff it against a committed expected value in CI.SHA-512 for a higher-assurance archive
Some long-term archival policies prefer SHA-512. The same run already produced it.
Archive manifest entry: file: Audit_Evidence.xlsx sha512: ee26b0dd4af7e749aa1a8ee3c10ae992... SHA-512 shares SHA-256's collision resistance with a longer digest — use it where policy mandates it; otherwise SHA-256 is sufficient.
Edge cases and what actually happens
An MD5 'match' is treated as proof of integrity
Invalid proofMD5 collisions are trivially constructible, so two different files can share an MD5. A matching MD5 therefore does not prove a file is the original. Always verify integrity on SHA-256; use the MD5 field only to populate a legacy system that demands it.
SHA-1 chosen as a 'middle ground'
Invalid proofSHA-1 has had practical collisions demonstrated since 2017 and is deprecated for integrity. It is in the report only for legacy interop. There is no reason to prefer SHA-1 over SHA-256 — SHA-256 is the same speed in Web Crypto and is collision-safe.
Wanting only MD5 to save space
Use SHA-256MD5's shorter digest is its only advantage and it is not worth the broken collision resistance. The tool computes all four regardless; record the SHA-256. Storage savings of 32 bytes are never worth an unreliable integrity proof.
Hash differs but only because the file was re-saved
By designAll four digests change when the .xlsx bytes change, including a re-save that only rewrote the Last-Modified XML. This is independent of algorithm choice — it is the hash correctly reflecting changed bytes. Capture the digest before any re-save.
Different tools report different MD5 for the same file
Check the bytesIf two tools disagree on MD5 (or SHA-256), one of them hashed different bytes — usually because a transfer altered the file, or one hashed a parsed/normalised form rather than the raw file. This tool hashes raw bytes; confirm both sides hash the identical file.
File exceeds the Free 5 MB cap
Tier limitFree tier caps input at 5 MB per file regardless of algorithm. Move to Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB) for larger files. Row count never matters — hashing is byte-only.
Expecting an algorithm picker in the UI
By designThere is no picker — the tool always returns all four digests. You select which one to record after the fact. This avoids the common mistake of generating only MD5 and discovering later that you need SHA-256.
Comparing this MD5 to another system's CRC32
Not comparableCRC32 is a checksum for accidental corruption, not a cryptographic hash, and the tool does not emit it. Do not compare across digest types — compare SHA-256 to SHA-256, MD5 to MD5. For integrity, only the SHA-2 family digests count.
Believing SHA-256 is slower than MD5 in the browser
Not a concernSHA-1/256/512 run through the browser's hardware-accelerated Web Crypto API; for typical Excel files all four resolve in under a second. Speed is not a reason to prefer the broken MD5 over SHA-256.
Frequently asked questions
Why is SHA-256 recommended over MD5 for Excel files?
MD5 has trivially constructible collisions — two different files can share an MD5 — so an MD5 match no longer proves a file is the original. SHA-256 has no known collisions and is what modern standards are built on, so a SHA-256 match is a genuine integrity guarantee. For legal, audit, or security use, SHA-256 is the right choice.
Does this tool make me pick MD5 or SHA-256?
No. There is no algorithm picker — a single run always returns SHA-1, SHA-256, SHA-512, and MD5 over the same bytes. You record whichever you need (SHA-256 for integrity, MD5 only for a legacy field) after the fact.
If MD5 is broken, why does the tool still produce it?
Purely for compatibility with legacy systems and basic non-security checksumming. Many older intake forms and audit tools still have an MD5 field. You can populate it from the report's md5 value, but you should record SHA-256 as your actual integrity proof.
Is SHA-1 a safe alternative to MD5?
No. SHA-1 has had practical collisions demonstrated since 2017 and is deprecated for integrity. It is in the report only for legacy interop. Use SHA-256, which is collision-safe and just as fast in the browser.
Is SHA-512 better than SHA-256?
It has a longer digest and the same collision resistance. SHA-256 is sufficient for virtually all integrity needs; choose SHA-512 only where a policy explicitly requires a longer digest. Both are produced in the same run.
Will the SHA-256 match other tools?
Yes. It is taken over the raw file bytes, so it matches sha256sum, shasum -a 256, and Node's crypto.createHash('sha256') on the same file. That reproducibility is what makes SHA-256 useful as a shared, verifiable fingerprint.
Can two different Excel files share a SHA-256?
No collision has ever been found for SHA-256 and finding one is considered infeasible. That is exactly the property MD5 lost. So a matching SHA-256 is treated as proof of byte-for-byte identity; a matching MD5 is not.
Is SHA-256 slower than MD5 in the browser?
No meaningful difference for Excel files. SHA-1/256/512 use the browser's hardware-accelerated Web Crypto API, and all four digests resolve in under a second for typical workbooks. Speed is not a reason to choose the broken MD5.
Does comparing algorithms upload my file?
No. All hashing runs in your browser via the Web Crypto API over bytes read locally. You can compare digests on a sensitive workbook without it leaving your device.
What about CRC32 — does the tool produce it?
No. CRC32 is a checksum for detecting accidental corruption, not a cryptographic hash, and is not emitted. For integrity verification use the SHA-2 family (SHA-256 / SHA-512); never use a non-cryptographic checksum as a tamper proof.
How large a file can I hash for free?
Up to 5 MB per file on the Free tier, one file per run, regardless of algorithm. Row count is irrelevant because hashing is byte-only. Larger files need Pro (50 MB), Pro + Media (200 MB), or Developer (500 MB).
Where does the hashing actually run?
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 and MD5 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.