A checksum answers a question about bytes
A cryptographic digest is a compact representation of a file’s bytes. If a trusted publisher supplies a SHA-256 checksum for a download, computing the same algorithm over your copy lets you check whether it matches. A mismatch means the bytes differ or the comparison used the wrong algorithm or expected value. It does not explain the cause without additional context.
This verifier computes SHA-256, SHA-384 or SHA-512 through Web Crypto and optionally compares an expected hexadecimal digest. It does not upload the file or scan it for malware. A matching checksum establishes consistency with the supplied value. The security benefit depends on obtaining that expected value from a source you have reason to trust independently of the downloaded file.
Choose the same algorithm as the publisher
Digest algorithms produce different outputs and lengths. SHA-256 produces 64 hexadecimal characters, SHA-384 produces 96 and SHA-512 produces 128. Select the algorithm named by the source of the expected checksum. A SHA-512 result should not be compared with a SHA-256 value, even though both appear as long strings of hexadecimal characters.
Paste only the checksum value into the expected field. Some checksum files include a filename, spaces and an indicator describing the file mode. This input expects the digest itself, so remove accompanying text. Uppercase and lowercase hexadecimal are treated equivalently. Internal spaces, missing characters and nonhexadecimal symbols are rejected instead of producing a misleading mismatch.
If you leave the expected value empty, the tool calculates a digest without claiming verification against a publisher. That mode is useful for documenting a file before transfer or comparing copies under your own control. It is not the same as verifying the origin of a download.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Understand the checksum’s trust chain
If an attacker can replace both a file and the checksum on the same unprotected page, the two can still match. Obtain checksums from an authenticated publisher channel, a signed release manifest or another trusted source appropriate to the software. For high-assurance distribution, a verified digital signature can provide stronger provenance than an unsigned checksum placed beside the download.
A checksum mismatch can result from an incomplete download, corruption, selecting a different release, choosing an archive instead of an extracted file or a publisher replacing a build. Do not immediately execute the file to see whether it works. Confirm the filename and version, compare the correct algorithm and download again through the official channel when appropriate.
The hash covers the bytes supplied by the file picker. Renaming a file does not normally change its contents and therefore does not change its digest. Editing metadata inside a document or image does change file bytes, even if the visible content looks the same. Recompressing an archive can similarly produce a different checksum while containing equivalent extracted files.
Plan for file size and browser memory
The Web Crypto digest interface used here processes an ArrayBuffer rather than a streamed file. The implementation therefore reads the selected file into browser memory and caps inputs at 100 MiB. That keeps the workload practical for a web utility, but devices with limited available memory can still struggle near the limit.
For large disk images or multi-gigabyte archives, use a trusted operating-system checksum utility that supports streaming. The mathematical digest should match when the algorithm and file bytes match, regardless of whether the computation happens in this browser or a command-line program. Record the algorithm alongside the value so a later comparison is reproducible.
After calculating the digest, download the report if you need an audit trail. It includes the filename, byte size, algorithm, computed digest and expected comparison result. A filename can itself contain sensitive information, so review it before sharing the report. Keep the original expected-checksum source as well; a report cannot reconstruct why you trusted that source.
Archive checksums refer to the exact compressed package unless the publisher specifies otherwise. Extracting files and hashing the resulting folder is a different operation with no universal byte representation. Compare the downloaded archive itself when the release page publishes a checksum for that archive.
Digest lengths and comparison outcomes
| Item | Interpretation |
|---|---|
| SHA-256 | 256-bit digest, represented by 64 hexadecimal characters. |
| SHA-384 | 384-bit digest, represented by 96 hexadecimal characters. |
| SHA-512 | 512-bit digest, represented by 128 hexadecimal characters. |
| Match | The computed digest equals the complete supplied value. |
| No expected value | A checksum was calculated, but no publisher comparison was performed. |
Strengths and limitations
What this is useful for
The verifier performs real cryptographic hashing and an exact digest comparison without a file upload. It validates expected digest length, distinguishes calculation from verification and exports a useful record. It works for any file type within the browser memory limit because the operation is defined over bytes.
What to keep in mind
A digest does not detect malware or establish publisher identity by itself. The expected value must come from a trustworthy source. This implementation reads the file into memory and limits size, so a streaming desktop utility is more appropriate for very large files or automated verification pipelines.
Common questions
Does a matching checksum mean a file is harmless?
No. A malicious file has a perfectly valid checksum. Matching proves consistency with the expected digest, not safety of the contents. Verify the publisher and release channel, then use appropriate malware scanning and operating-system protections before opening or executing unfamiliar material.
Why does changing the filename leave the hash unchanged?
The digest is computed from file contents, not the external filename shown by the operating system. Changing embedded document metadata or archive contents is different because those bytes are inside the file. The report records the name for context without incorporating it into the digest.
Is the selected file transmitted anywhere?
No. The file is read and hashed locally using Web Crypto. The application does not send it to an analysis service. An exported report contains the filename and hash, but not the complete file bytes. Browser extensions and the operating system remain separate trust considerations.
Can I use this to hash a password for storage?
A fast general-purpose digest is not a suitable password-storage scheme. Password databases need a purpose-designed password-hashing or derivation function with appropriate parameters and salts. This tool is for file-integrity comparison, not designing an authentication database.