Calculate file checksums and compare them exactly
A checksum is a repeatable fingerprint of file bytes. Matching a value published by a trusted source can show that your downloaded bytes match that source's reference.
A checksum does not prove that a file is harmless, that the publisher is trustworthy, or that a reference value was not replaced by an attacker. The comparison is only as trustworthy as the channel that supplied the expected digest.
Start with the origin of the expected value
A digest copied from the same compromised download page as the file may be replaced alongside it. Prefer a signed release, authenticated repository, separate announcement, or another trusted channel.
Record the exact filename, version, platform, architecture, and algorithm. Publishers often provide several files with similar names and different checksums.
Algorithms are not interchangeable
An SHA-256 value cannot be compared with SHA-512 or MD5. Select exactly the published algorithm and compare the complete hexadecimal output.
CRC32 detects common transfer errors but is easy to manipulate. MD5 and SHA-1 have collision weaknesses and should not be chosen for new adversarial integrity designs, though legacy publishers may still provide them for compatibility.
Understand what a match establishes
A match indicates that the local file bytes agree with the referenced bytes under that algorithm. Renaming the file does not normally matter because the filename is not hashed.
A match does not scan for malware, audit source code, or establish publisher identity. If the trusted reference describes a harmful file, the matching digest faithfully identifies that harmful file.
Combine checksums with signatures and source review
For software, verify a platform signature, package signature, or signed release when available. Check the publisher domain and release notes as well as the digest.
Keep a record of the expected value and its source when verification matters later. Recalculate after any operation that changes file bytes, including re-archiving or metadata updates.
Protect the reference value, not only the comparison step
Checksum verification is only as trustworthy as the expected value. Prefer a digest published through an authenticated channel controlled by the software or data publisher. If the file and checksum arrive from the same untrusted message or compromised website, an attacker may replace both. Record the algorithm alongside the value, because identical-looking hexadecimal strings can represent different digest families and lengths. For high-assurance software, verify a signed release or package signature when one is available. A matching checksum then confirms the bytes you received match the referenced bytes; it still does not certify that those bytes are safe or suitable.
Quick start: LocalUtils
- Obtain the expected checksum from the software publisher or another authenticated channel.
- Choose the same algorithm named by the publisher; values from different algorithms cannot be compared.
- Select the file and let the worker finish without modifying or re-downloading it.
- Compare the complete hexadecimal strings, preferably by copy/paste into a constant-time or exact text comparison rather than checking only the first characters.
What the browser does
A Web Worker reads the file and calculates selected algorithms, including CRC32, MD5, SHA-1, SHA-256, SHA-384, SHA-512, and SHA-3 variants implemented by the bundled libraries.
The file bytes remain in the browser processing path. Older algorithms remain useful for compatibility and accidental-corruption checks, but MD5 and SHA-1 are not suitable choices for new collision-resistant security designs.
Inputs and outputs
- Input: any local file readable by the browser File API.
- Output: hexadecimal digest strings for the selected algorithms.
- A digest identifies exact bytes; changing one byte, metadata field, or archive timestamp normally changes the result.
Limits to know before you start
- A matching digest cannot detect malware when the trusted reference describes the same malicious file.
- CRC32 is an error-detection checksum, not a cryptographic integrity proof.
- MD5 and SHA-1 have known collision weaknesses.
- Large files take time to read and still consume device I/O and processing resources.
Verification checklist
- Confirm the reference checksum was obtained over HTTPS or a signed release channel.
- Compare the entire digest with matching capitalization ignored only when the representation is hexadecimal.
- For high-assurance software, verify a digital signature in addition to the checksum.
Troubleshooting
- If values differ, confirm algorithm, file version, architecture, decompression state, and whether the publisher hashes an archive or its contents.
- Copy the checksum without spaces, labels, or hidden line breaks.
- Recalculate after a fresh download only when the expected value comes from a trusted independent source.
Questions people ask
Should checksums be case-sensitive?
Hexadecimal letters can usually be compared without case, but every digit and letter position must otherwise match.
Why do two visually identical files hash differently?
Metadata, compression settings, object order, timestamps, or invisible bytes can differ even when rendered content looks the same.
Is SHA-256 enough?
It is a widely used modern digest, but trustworthy distribution also depends on how the expected value and publisher identity are authenticated.