SHA-256 File Checksum Generator
A checksum answers one question: is this file byte-for-byte identical to the one the publisher released. Uploading a file to a website to answer that question rather defeats the purpose, so this computes the digest in the page using the browser native Web Crypto implementation.
How to use it
- Drop in any file. Size and type do not matter.
- The file is read into memory and hashed with the browser Web Crypto API.
- Download the hex digest and compare it against the published value.
What a matching hash actually proves
SHA-256 produces a 256-bit digest, written as 64 hexadecimal characters. Change a single bit anywhere in the input and roughly half the output bits change, which is why comparing the first and last few characters is a reasonable shortcut for spotting a mismatch.
A match proves the bytes are identical to whatever produced the reference hash. That is a strong statement about integrity and a weak one about trust. If an attacker can modify the download, they can usually modify the hash published next to it. Checksums served over the same channel as the file protect against corruption and mirror problems, not against a compromised publisher. Signed hashes, where the digest is signed with a key you already trust, are what close that gap.
Why not MD5 or SHA-1
Both are still widely published and both are broken for security purposes. MD5 collisions can be produced in seconds on ordinary hardware, and SHA-1 collisions were demonstrated in practice in 2017. An attacker who can generate two files with the same digest can substitute one for the other undetected.
They remain adequate for detecting accidental corruption, which is a different threat model entirely. If a project publishes only an MD5, treat it as a transfer check rather than a security guarantee.
Not a password hash
SHA-256 is designed to be fast, and that is exactly the wrong property for storing passwords. Modern hardware computes billions of SHA-256 operations per second, so a bare SHA-256 of a password falls quickly to a dictionary or brute-force attack.
Password storage needs a deliberately slow, salted, memory-hard function such as Argon2, scrypt, or bcrypt. The slowness is the feature.
At a glance
| Accepted input | Any file type |
|---|---|
| Algorithm | SHA-256, via Web Crypto SubtleCrypto |
| Output | 64-character lowercase hex digest |
| Upload | None, the file is read into local memory only |
Frequently asked questions
Does the file get uploaded to check the hash?
No, and that is the point. The file is read into browser memory and hashed by the browser own cryptographic implementation. Nothing is transmitted.
My hash does not match the published one. What now?
Re-download the file first, since truncated or interrupted transfers are by far the most common cause. Also confirm you are comparing against the right algorithm, as projects often publish SHA-256, SHA-512, and MD5 side by side. If it still differs after a clean download, do not run the file.
Is there a file size limit?
The file has to fit in browser memory to be hashed, so very large disk images may fail on a low-memory machine. Multi-gigabyte files are more reliably hashed with a command-line tool that streams.
Can I use this to hash a password?
You can, but you should not. SHA-256 is fast by design, which makes it a poor choice for passwords. Use Argon2, scrypt, or bcrypt, all of which are deliberately slow and salted.
Read more
CSV, JSON, YAML, XML: choosing a data format — Every conversion between these formats loses something. Knowing what, in advance, prevents most of the resulting bugs.