File Checksum Generator
Generate a checksum from the exact bytes of a local file, without uploading the file to a hash service. Choose SHA-256 for the usual integrity check, or select SHA-1, SHA-384, or SHA-512 when a published manifest explicitly requires that algorithm. The result is lowercase hexadecimal and can be compared with a vendor checksum for an installer, archive, document, image, or build artifact. The browser reads the selected file only after you choose it; the page does not send the bytes to a server. A matching hash confirms bytes match a reference, but it does not prove that the reference itself came from a trustworthy publisher.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Exact local file-byte hashing
- SHA-256 default
- SHA-1, SHA-384, and SHA-512 choices
- File size and algorithm display
- No upload or server-side storage
How to use File Checksum Generator
- 1
Choose the file
Select the downloaded or local artifact. The browser receives a File handle and reads its bytes for the digest; the filename is shown only as local page state.
- 2
Select the published algorithm
Match the algorithm named by the vendor or release manifest. SHA-256 is a good default when no older compatibility requirement exists.
- 3
Compare the checksum
Compare every hexadecimal character with the trusted reference. If one character differs, the selected file is not byte-for-byte identical to that reference.
- 4
Keep the evidence
Record the source URL, algorithm, checksum, and download time when verifying an artifact for a release or incident. A hash alone is not a signature.
How it works
Operational use
For a download, calculate the digest after the file has finished downloading and before opening or modifying it. Compare it with a value published through a separate trusted channel, not with a value copied from the same unverified page as the file. If the values differ, download again, check that the algorithm matches, and compare file size and source URL without assuming that one side is correct. For build artifacts, record the version, platform, compression state, and exact command that produced the reference. For text, decide whether the hash covers the raw text, normalized text, or encoded bytes. That decision is part of the verification procedure and should be documented beside the checksum.
A checksum is not authentication
The digest is useful when you already trust the reference value and need to detect a changed download or incomplete copy. It does not identify the publisher, prove that a file is safe, or show that the reference digest came from the right person. Record the algorithm and hash the same representation each time. Text hashing can change with line endings, Unicode normalization, whitespace, or encoding. File hashing can change when metadata or archives are repackaged. For a release, obtain the reference from an authenticated source and keep the original and verified copy separate.
The browser's File API exposes the selected file as an ArrayBuffer. The page sends
that byte sequence to crypto.subtle.digest with the selected SHA algorithm. It does
not decode the file as text, strip a byte-order mark, normalize line endings, or
re-encode the content. That is essential for installers, archives, PDFs, and images,
where treating bytes as text would change or reject the input.
The binary digest is rendered as two lowercase hexadecimal characters per byte. The algorithm and file size remain visible so a copied checksum has enough context to review. Files are not stored by this page, but selecting a file does grant the browser access to read it during the current interaction. Clear the selection after use on a shared computer.
When to use it
Use this to verify a release download, compare a backup copy, check a generated build artifact, or document the exact file used in a test. It is not a malware scanner, digital signature verifier, or password hashing tool. For a supply-chain decision, combine the checksum with a trusted transport channel, signed manifest, and the publisher's release process.
Examples
Checking a downloaded archive
The checksum changes if the archive is recompressed, renamed is irrelevant to the bytes, or one byte is modified. Compare it with the publisher's release page, not a checksum copied from an untrusted mirror.
Comparing two document copies
Two visually identical documents can still have different metadata or object ordering and therefore different bytes. A checksum is an exact file comparison, not a visual similarity test.
Frequently asked questions
Does a file checksum prove that a download is safe?
No. It proves only that the bytes match the reference checksum you used. If an attacker changed both the file and the checksum source, the comparison would still appear valid. Obtain the reference through a trusted publisher channel and prefer signed releases when authenticity matters.
Does the checksum tool upload my file?
No. The browser reads the selected File object and passes its bytes to Web Crypto locally. The page does not need a file conversion endpoint. A very large file can still use device memory and browser resources, and a managed computer may have its own monitoring outside this page's control.
Why is the checksum different after opening and saving a file?
Opening and saving can rewrite metadata, compression, line endings, object order, or embedded timestamps. A checksum compares bytes, so a visually identical file can have a different digest after re-export. Use a visual comparison tool when appearance is the requirement and a checksum when exact identity is the requirement.
Which algorithm should I choose?
Choose the algorithm named by the trusted checksum source. SHA-256 is the common modern default and produces 64 hexadecimal characters. SHA-512 produces a longer digest, while SHA-1 is retained here for compatibility checks rather than new security design. Do not invent an algorithm choice after seeing a mismatch.
Further reading
- Hex Is Twice the Size of Your Data, Base64 Is a Third MoreHex and base64 solve the same problem — get binary through a channel that only carries text — and one of them costs six times as much as the other. Hex still turns up constantly, and usually for a reason that has nothing to do with size.
- How to Check Whether a Conversion Actually Kept Your FileEvery conversion tool reports success. None of them report what they threw away, because from the tool's point of view nothing went wrong — it did the conversion it was asked for, and the things the destination format cannot hold were discarded before compression even started. Here is how to find out what you actually got.
- Saving as UTF-16 More Than Doubled the File, for No BenefitText editors offer an encoding dropdown with several UTF options and no guidance. Choosing the wrong one produces a file that is more than twice the size, that many tools will not read, and that looks like it is full of null bytes when anything goes wrong. Here is the size difference measured, and when UTF-16 is actually the right answer.