Tools · Hashing and verification
Hash generator
Hash text or a file of any size with MD5, SHA-2, SHA-3, BLAKE2 or BLAKE3. Nothing leaves your browser.
Nothing you type or drop here leaves your browser. Files are read in 4 MB pieces by a background worker and never uploaded.
This hash generator computes MD5, SHA-1, SHA-256, SHA-512, SHA-3, BLAKE2, BLAKE3 and more from text or a file, all at once, in your browser. Nothing is uploaded. The results match sha256sum and openssl dgst byte for byte, so it's a quick way to check a download or see what one changed letter does to a digest.
Using it
Type or paste text and every ticked algorithm updates as you type. The text is turned into UTF-8 bytes before it's hashed, which is what almost every command-line tool does, so the output matches sha256sum, shasum -a 256 and openssl dgst when you give them the same bytes. To hash a file, drop it on the box. A 4 GB disk image is fine, because the file is read a piece at a time and never has to fit in memory.
If you already have the checksum a publisher printed beside a download and only want to know whether your copy matches, use the file checksum verifier. It works out the algorithm from the checksum's length and does the comparison for you. To check two digests against each other, there's the hash comparer, and if you've got a hash and no idea what made it, the hash identifier narrows it down.
Why the digests come out different lengths
A hash function turns any amount of input into a fixed-size digest, and the size is part of the algorithm's definition. MD5 makes 128 bits (32 hex characters), SHA-1 160 bits (40), SHA-256 256 bits (64) and SHA-512 512 bits (128). Change one letter and about half the output bits flip. That's the avalanche effect. The table shows the digests of one sentence against the same sentence with dog changed to cog. scripts/examples/hash-examples.mjs computed the numbers, and it's the same code this page runs:
| Algorithm | Output bits | Bits that differ, dog → cog |
|---|---|---|
| MD5 | 128 | 71 (55.5%) |
| SHA-1 | 160 | 87 (54.4%) |
| SHA-256 | 256 | 123 (48.0%) |
| SHA-512 | 512 | 253 (49.4%) |
| SHA3-256 | 256 | 130 (50.8%) |
| BLAKE3 | 256 | 125 (48.8%) |
In a well-behaved hash every output bit flips with probability one half whatever you change, so the counts hover near 50%. For 128-bit MD5 that means 64 bits, and we got 71. The default sentence, The quick brown fox jumps over the lazy dog, has the MD5 9e107d9d372bb6826bd81d3542a419d6 and a SHA-256 that starts d7a8fbb3 and ends c9e592. If your tool shows something else, the input bytes differ, and the usual culprit is a trailing newline.
Which hash should you pick?
| Job | Use | Notes |
|---|---|---|
| Check a download against a published checksum | whatever the publisher gave | SHA-256 is the usual one. See how to verify a download |
| Detect accidental corruption | CRC-32, or any of the above | CRC-32 is quick, tiny, and trivially forged on purpose |
| Fingerprint files for deduplication or sync | BLAKE3 or SHA-256 | BLAKE3 is much faster on big files |
| Anything an attacker could try to forge | SHA-256, SHA-512 or SHA3-256 | With a key, use HMAC |
| Storing passwords | none of these | Use a deliberately slow, salted function: bcrypt, scrypt, Argon2 or PBKDF2. See the PBKDF2 article |
| Matching an old checksum | MD5 or SHA-1 | Only for matching; both are broken against deliberate collisions |
MD5 and SHA-1 are broken in one specific way: people can build two different files with the same digest. Wang, Feng, Lai and Yu published the first practical MD5 collisions in 2004, and CWI Amsterdam and Google produced the first SHA-1 collision in 2017 (the SHAttered attack). That doesn't stop either one from catching a flipped bit in a download, and it doesn't make their digests reversible. What it means is that they can't stop someone who chose the file on purpose. The results mark them checksums only.
CRC-32 and Adler-32 carry a not a security hash tag. They exist to catch random errors in zip files, PNG images and network frames, and anyone can build a file with whatever CRC they like.
The algorithms, briefly
- SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/256) came from NIST in 2001 and is defined in FIPS 180-4. SHA-256 is what TLS certificates, Git's newer object format, package managers and Bitcoin use.
- SHA-3 (here SHA3-256 and SHA3-512) is a different design built on the Keccak sponge, standardized as FIPS 202 in 2015. An open competition picked it as a fallback in case SHA-2 ever fell, and nobody has needed it yet.
- BLAKE2b and BLAKE2s are specified in RFC 7693. BLAKE3 is a newer tree-structured design, and it's very fast on large inputs because it can hash pieces in parallel.
- RIPEMD-160 is a 1996 design that still sits inside Bitcoin addresses.
The code is Paul Miller's MIT-licensed @noble/hashes library, vendored as one file, with CRC-32 and Adler-32 written by us. Every algorithm is tested against the official published vectors (FIPS, RFC 1321, RFC 7693) and against Node's own OpenSSL-backed implementation on every change. The test count is on cipher.ink by the numbers.
Common questions
Is a hash the same as encryption?
No. Encryption can be undone with a key, while a hash is a one-way fingerprint with no key and no way back. You can't get the text out of a digest, though you can find a short or guessable input by trying candidates, which is why password hashing needs a slow function.
Why does my hash differ from another tool's?
Almost always the input bytes differ. The usual causes are a trailing newline (echo adds one, while printf and echo -n don't), Windows line endings, or a different text encoding. Hash the file itself instead of text you retyped.
Is my file uploaded?
No. The page's Content-Security-Policy allows connections only to cipher.ink itself, this tool makes none, and a Web Worker reads the file locally.
How big a file can it hash?
Browsers can read very large files in slices, so time limits you, not memory. As a rough guide, SHA-256 in JavaScript manages a few hundred megabytes a second on a laptop, and BLAKE3 is several times faster.
Can I hash text with a secret key?
That's a message authentication code, not a plain hash. Use the HMAC generator.
Does cipher.ink use these hashes?
It uses SHA-256 for the receipt token (the server stores only the token's hash) and inside PBKDF2 for passphrase keys. The messages themselves are encrypted with AES-256-GCM, not hashed. See how it works.