Multi-hash Generator
Hash one input with 16 algorithms at once — MD5 to BLAKE3 — and see which rows match a digest you already hold, entirely on this device.
…or drop a file on the input — files are hashed on this device, never uploaded.
Paste a hex digest to highlight rows of the same length.
| Algorithm | Digest (hex) | Copy |
|---|---|---|
| MD5 | ||
| SHA-1 | ||
| SHA-224 | ||
| SHA-256 | ||
| SHA-384 | ||
| SHA-512 | ||
| SHA3-256 | ||
| SHA3-512 | ||
| Keccak-256 | ||
| BLAKE2b-512 | ||
| BLAKE2s-256 | ||
| BLAKE3 | ||
| RIPEMD-160 | ||
| CRC32 | ||
| Adler-32 | ||
| xxHash64 |
Keccak-256 and SHA3-256 never match: Ethereum uses the original Keccak padding, while the standardized SHA-3 (FIPS 202) changed it.
Press ? for shortcuts
Do it offline:$ for h in md5 sha1 sha256 sha512; do openssl dgst -$h release.tar.gz; done
How to use it
- Type or paste the input. It hashes as UTF-8 text by default; switch to the hex or Base64 interpretation when the box holds encoded bytes.
- Read the table as it fills: the browser-native rows — SHA-1, SHA-256, SHA-384, SHA-512 — land first, and the WebAssembly rows follow without blocking typing. Copy one row, or Copy all for algorithm: digest lines.
- To hash a file, drop it on the input or use the picker: one pass streams it through all sixteen hashers, with progress and a working Cancel. Typed text comes back when you remove the file.
- To identify a digest, paste it into the match field: rows of that exact length light up — a 40-character value narrows to SHA-1 and RIPEMD-160.
Paste text — or drop a file up to 64 MB — and every digest appears in one pass: MD5, the SHA-2 and SHA-3 families, Keccak-256, BLAKE2, BLAKE3, RIPEMD-160, plus the CRC32, Adler-32 and xxHash64 checksums. Sixteen rows, computed on this device, never uploaded. Paste a digest you already hold and the length-match assistant highlights which algorithms could have produced it.
Examples
helloMD5: 5d41402abc4b2a76b9719d911017c592
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
CRC32: 3610a686Three of the sixteen rows for the five bytes of hello. Width is fixed per algorithm regardless of input size: MD5 always 32 hex characters, SHA-256 always 64, CRC32 always 8.
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434dSHA-1, RIPEMD-160This 40-character value is SHA-1 of hello; the assistant highlights the two rows of exactly that length. Length narrows the field — it cannot prove which algorithm made a digest.
hello
MD5: b1946ac92492d2347c6235b4d2611184One trailing newline, a completely different digest from example 1. The tool flags exactly this: "Input ends with a trailing newline, which is included in every digest — echo adds one, printf does not."
68656c6c6fSHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824In the hex interpretation these ten characters decode to the same five bytes as typing hello, so all sixteen rows repeat example 1 exactly. Digests are functions of bytes, not spellings.
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Keccak-256 and SHA3-256 never agree
Ethereum adopted Keccak before NIST finalized SHA-3, and FIPS 202 changed the padding rule. Empty input shows the split: Keccak-256 gives c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, SHA3-256 gives a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a. Check which one your document means — both rows are here.
Four rows are native, twelve are WebAssembly
SHA-1, SHA-256, SHA-384 and SHA-512 come from the browser's WebCrypto and appear instantly; the other twelve compute in a background worker. Pending rows hold their place, and a failed module reports itself while the rest keep working.
A file is read once, not sixteen times
File hashing feeds each chunk to all sixteen incremental hashers in one pass, so disk work never multiplies with the row count: one progress bar, every digest at the end.
The ceilings: 1 MB of text, 64 MB per file
Text past 1 MB is refused with a typed error — hashing part of your input would produce a wrong answer, so nothing is truncated. Files past 64 MB hand off to the File Checksum Verifier.
CRC32, Adler-32 and xxHash64 are not security tools
The three short rows — 8 or 16 hex characters — are checksums: fast detectors of accidental corruption, useful cache keys. Anyone can construct an input hitting a chosen checksum, so they prove nothing about tampering.
Common errors
`g` at position 4 is not a hex digit- Hex accepts 0-9 and a-f in either case, tolerating whitespace separators and a 0x prefix. The message pinpoints the first character outside that; your input stays untouched.
Odd number of hex digits — byte 2 is incomplete- Bytes are two hex digits, so decodable hex has an even count. A lone final digit usually means a truncated copy; nothing is hashed until the byte is whole.
Base64 length is invalid — 1 stray character- Base64 maps three bytes to four characters, so a length of 4n+1 never decodes; whitespace, data: URI prefixes and the URL-safe alphabet are tolerated with chips.
Input is larger than the 1 MB limit for this tool. For bigger payloads use the CLI: for h in md5 sha1 sha256 sha512; do openssl dgst -$h release.tar.gz; done- Over-limit text is refused as a typed error rather than partially hashed. The banner repeats this page's CLI, which digests any file without a browser tab.
This file is larger than the 64 MB limit for in-page hashing — the File Checksum Verifier streams files of any size.- 64 MB keeps sixteen simultaneous hashers responsive; past it, the dedicated verifier is the right tool. The refusal names it and leaves your input as it was.
FAQ
Which hash algorithm should I use for new work?
SHA-256: standardized in FIPS 180-4, hardware-accelerated on most CPUs, and the digest most tooling expects. BLAKE3 is faster still on large inputs. MD5 and SHA-1 are legacy interop only — practical collisions exist for both, so never for new signatures. None of these sixteen is a password hash: passwords need a deliberately slow KDF such as Argon2 or bcrypt.
Why is my Keccak-256 result different from SHA3-256?
They are two functions: FIPS 202 adopted Keccak as SHA-3 but changed the message padding, so every digest differs. Ethereum standardized on original Keccak-256 before the final standard existed — an Ethereum document saying "SHA-3" almost always means Keccak-256. This page shows both rows.
Can I reverse a hash to get the input back?
No. A digest is fixed-size — 32 bytes for SHA-256 — while inputs are unbounded, so infinitely many inputs share every digest. Lookup sites match digests against precomputed tables of common inputs — recognition, not reversal. e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 is simply SHA-256 of empty input — why a bare unsalted hash protects nothing secret.
Keyboard shortcuts
- ⌘/Ctrl + Enter
- Re-run hashing on the current input.
- ⌘/Ctrl + S
- Download the manifest as .txt — the algorithm: digest lines Copy all produces.
- ⌘/Ctrl + C
- Copy every computed row when nothing is selected; a selection still copies normally.
- ⌘/Ctrl + Shift + C
- Copy all rows even while a selection is active.
- t
- Cycle the color theme (outside text fields).
- ? or ⌘/Ctrl + /
- Open the shortcut help overlay.
- Esc
- Close an open dialog.