MD5, SHA-1 and SHA-256 hash generator
Generate MD5, SHA-1, SHA-256, SHA-384 and SHA-512 checksums for text or any file, compare against an expected hash, and verify downloads locally.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
0 characters · 0 B of UTF-8
| Algorithm | Digest (hex) | Copy |
|---|---|---|
MD5 128-bit · broken for security, still common for download checksums | — | |
SHA-1 160-bit · collisions demonstrated in 2017, legacy use only | — | |
SHA-256 256-bit · the current default for integrity and signatures | — | |
SHA-384 384-bit · SHA-2 family, truncated SHA-512 | — | |
SHA-512 512-bit · SHA-2 family, faster than SHA-256 on 64-bit CPUs | — |
Case and surrounding whitespace are ignored. The comparison runs over the whole string, so it does not leak where a mismatch starts.
How to generate a checksum
- Text — type or paste, and all five digests appear at once. The exact UTF-8 bytes in the box are hashed; no trailing newline is added.
- File — drop a file, tick the algorithms you need, and press Compute. Files are read in 4 MB slices with a progress bar, so a multi-gigabyte image is fine.
- Paste the publisher's checksum into the compare box. The matching row is flagged, and a badge tells you whether anything matched at all.
- Switch to uppercase output if you are comparing against a value from a Windows tool or a certificate viewer.
Verifying a download
A checksum published next to a download exists so you can prove the bytes you received are the bytes
the publisher shipped — that no mirror corrupted them and no proxy tampered with them. Doing that check
on a website that uploads your file defeats the purpose entirely: you would be trusting an unknown
third party with the file and with the verdict. Here the file never leaves your machine, so the
verification is as trustworthy as running sha256sum locally.
One thing a checksum cannot do on its own: prove the publisher is who they say they are. If an attacker controls the download page, they control the checksum printed on it too. For that you need a signature (GPG, Sigstore, code signing) whose key you obtained separately.
Choosing an algorithm
| Algorithm | Output | Status | Reasonable use today |
|---|---|---|---|
| MD5 | 128 bits, 32 hex characters | Collision-broken since 2004 | Matching a legacy checksum, cache keys, non-security dedup |
| SHA-1 | 160 bits, 40 hex characters | Collision demonstrated in 2017 (SHAttered) | Git object ids, legacy checksums |
| SHA-256 | 256 bits, 64 hex characters | Secure | The default choice for integrity, signatures and fingerprints |
| SHA-384 | 384 bits, 96 hex characters | Secure | Subresource integrity, TLS suites that specify it |
| SHA-512 | 512 bits, 128 hex characters | Secure | Often faster than SHA-256 on 64-bit CPUs |
"Broken" means an attacker can construct two different inputs with the same digest. It does not mean they can find an input that matches your existing digest — that is a preimage attack, and it remains infeasible even for MD5. So an old MD5 checksum still catches accidental corruption; it just cannot defend against a deliberate forger.
Never hash a password with these
MD5 and the SHA family are designed to be fast, which is exactly the wrong property for password storage — a modern GPU computes billions of SHA-256 hashes per second. Passwords need a deliberately slow, memory-hard, salted function: Argon2id, scrypt or bcrypt. Use a hash here for integrity, never for credentials.
Why your hash differs from someone else's
- A trailing newline.
echo "abc"in a shell appends one;echo -n "abc"does not. The two produce completely different digests. - Line endings. A file checked out with CRLF on Windows hashes differently from the same file with LF.
- Text encoding. The same characters encoded as UTF-8 and UTF-16 are different bytes. This tool always uses UTF-8.
- A byte-order mark. An invisible BOM at the start of a file changes everything downstream.
How the hashing is done
SHA-1, SHA-256, SHA-384 and SHA-512 use crypto.subtle.digest, the browser's native
implementation — the same code path your TLS stack uses, running at native speed. MD5 is not offered by
WebCrypto (deliberately, because it is broken), so this page ships a small, plain JavaScript
implementation of RFC 1321 that processes the file incrementally, block by block, as it streams in.
Questions
Can I hash a large ISO or archive?
Yes. Files are read in 4 MB slices and fed to the digest incrementally with a progress bar, so multi-gigabyte files hash without loading the whole thing into memory at once.
Why offer MD5 and SHA-1 if they are broken?
Both are cryptographically broken for signatures, but they remain the checksum published alongside many downloads and stored in legacy databases. Use them to match an existing value, and SHA-256 for anything new.
How do I verify a downloaded file?
Pick the algorithm the publisher used, drop the file in, paste their published value into the compare box, and the tool reports a match or mismatch after a constant-time-style comparison of the two strings.
Does the file get uploaded to check the hash?
No. Hashing uses the browser WebCrypto API for the SHA family and a JavaScript MD5 implementation, both running locally. The file never leaves the machine, which is the whole point of verifying it yourself.
Why does the same text give a different hash elsewhere?
Almost always a trailing newline or a different text encoding. This tool hashes the exact UTF-8 bytes of what is in the box, with no newline added, so paste carefully.