BLAKE2b Hash Generator & Verifier
Generate and verify BLAKE2b hashes in your browser. Choose any output length from 1 to 64 bytes, switch on BLAKE2b's native keyed mode with a key up to 64 bytes, hash text in UTF-8/UTF-16/Latin-1/Windows-1252 or raw hex and base64, stream multi-gigabyte files, and compare the result against a b2sum checksum.
A BLAKE2b digest is only reproducible with the same length and key
The requested output length and the key are both mixed into BLAKE2b's parameter block before the first byte of input is absorbed. That means BLAKE2b-256 is not the first 32 bytes of BLAKE2b-512, and a keyed digest shares nothing with the unkeyed one. If a digest you were given does not match, check the length and the key before you suspect the data.
Runs entirely in your browser. No browser exposes BLAKE2b through the Web Crypto API, so text, files and keys are hashed by a WebAssembly module served from this site — no CDN script, nothing uploaded, nothing logged. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear after the one-time wasm fetch.
BLAKE2b-512 digest
0 bytes hashed — canonical empty-input digestFix the parameters above to see a digest.
Input
Any length from 1 to 64 bytes is legal. The length is mixed into BLAKE2b's parameter block, so BLAKE2b-256 is not BLAKE2b-512 cut in half — the two share no prefix at all.
0 characters · 0 encoded bytes
UTF-8 is what b2sum, libsodium's crypto_generichash and every modern web API see. Leave it selected unless you are reproducing a legacy system's hash.
Compare against an expected hash
Paste the expected digest — bare hex, base64, a b2sum line (hash filename) or a BSD BLAKE2b (file) = hash tag all work. Only candidates of exactly 64 bytes are considered, so a digest of a different length is reported as such instead of silently mismatching.
The verdict appears as soon as both a digest and an expected hash exist. Hex is compared case-insensitively; base64 is compared case-sensitively, because a and A are different six-bit values.
The same input in five algorithms
Compute BLAKE2b-512, BLAKE2s-256, BLAKE3-256, SHA-256 and SHA3-256 of the same input side by side — the quickest way to work out which algorithm produced a digest, since four of the five are 64 hex characters long.
Do not store passwords with BLAKE2b
BLAKE2b is built for throughput — gigabytes per second on one core, and a GPU runs it in parallel by the billion. That is exactly wrong for password storage, salted or not. The right way to use BLAKE2b on a password is indirectly: Argon2 uses BLAKE2b as its internal compression primitive and wraps it in the memory-hard work factor that makes brute force expensive. Argon2id is the OWASP default; alternatives are bcrypt (cost ≥ 12), scrypt and PBKDF2.
Why two tools disagree about "the" BLAKE2b of your data
- • A different output length. The most common cause. Many libraries default to 32 bytes (libsodium's
crypto_generichash) whileb2sumand this tool default to 64. The digests share no prefix. - • Keyed vs unkeyed. A key changes the parameter block, so a keyed digest is unrelated to the unkeyed one even with an identical message.
- • BLAKE2b vs BLAKE2s. Both are RFC 7693 and both can output 32 bytes — and they never agree. Check which word size the other side used.
- • Salt and personalisation. BLAKE2 also has optional 16-byte salt and personalisation fields. This tool leaves both zero, which is what
b2sumand most libraries do; a tool that sets them produces a different digest. - • A trailing newline or a BOM.
echo "abc" | b2sumhashes 4 bytes, not 3, and a UTF-16 file from a Windows editor starts with 2 extra bytes.
Technical specifications
- • Algorithm: BLAKE2b (RFC 7693, 2015), derived from BLAKE — a finalist in NIST's SHA-3 competition. BLAKE2 itself is not a NIST standard.
- • Internals: 64-bit words, 12 rounds, 128-byte blocks, HAIFA-style counter, ChaCha-derived G function
- • Output: 1–64 bytes, chosen per digest and mixed into the parameter block (currently 64 bytes = 512 bits)
- • Keyed mode: native, key of 1–64 bytes padded to one block and absorbed first — a MAC without HMAC's nested construction
- • Security: n/2-bit collision resistance and n-bit preimage resistance for an n-bit digest; no known attacks on the full-round function
- • Length extension: not applicable — BLAKE2 finalises with a last-block flag, so
BLAKE2b(key ‖ message)is a sound MAC whereSHA-256(key ‖ message)is not - • Empty input: BLAKE2b-512 of zero bytes is
786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce - • Engine: hash-wasm WebAssembly, 4 MiB streaming chunks for files
- • Not exposed here: the optional salt and personalisation fields, and the BLAKE2bp/BLAKE2X tree variants
Common use cases
H' and its compression function — see the Argon2 tool.crypto_generichash is BLAKE2b, defaulting to a 32-byte output and accepting an optional key.blake2b-256, Zcash, Monero's slow-hash inputs and several Cargo/Nix-style content stores.b2sum, so BLAKE2b-512 is a first-class alternative to sha256sum on any modern Linux box.About BLAKE2b Hash Generator & Verifier
The BLAKE2b Hash Generator & Verifier computes BLAKE2b digests of text or files and checks them against a hash you already have — entirely inside your browser, through a WebAssembly build of the algorithm. BLAKE2b is the 64-bit member of BLAKE2 (RFC 7693), and unlike SHA-256 it has two parameters that change the result: the output length, which can be any value from 1 to 64 bytes, and an optional key of up to 64 bytes that turns the hash into a MAC. Both are exposed here instead of being hidden behind a default, because a BLAKE2b digest is only reproducible when both sides agree on them.
Why use a BLAKE2b Hash Generator & Verifier?
Most online BLAKE2b tools offer a single fixed length, no keyed mode, and no way to tell whether a mismatch came from the data or from a parameter. This one shows the length and the key explicitly, refuses an over-long key with a clear message instead of silently truncating it, hashes files by streaming them in 4 MiB chunks so a multi-gigabyte image never enters memory in one piece, allows empty input so you can read off the canonical zero-byte digest, and compares hex case-insensitively while comparing base64 case-sensitively — because base64 is a case-significant alphabet and lowercasing both sides would 'verify' two different digests.
Who is it for?
Developers reproducing a libsodium crypto_generichash value, release engineers checking a b2sum line, Argon2 and Zcash implementers debugging an internal BLAKE2b call, protocol designers evaluating keyed BLAKE2b against HMAC-SHA256, and anyone whose BLAKE2b digest disagrees with another implementation and needs to find out whether the cause is the length, the key or the bytes.
How to use the tool
Choose Hash Text to hash typed input, or Hash File to checksum a file from disk.
Set the output length in bytes — anything from 1 to 64. The presets cover 16, 20, 32, 48 and the 64-byte default that b2sum and OpenSSL use.
In text mode, type or paste your input: the digest updates live above the input box, and an empty box shows the canonical zero-byte digest 786a02f7…be2ce.
Pick the input encoding — UTF-8 (the default), UTF-16LE/BE, ISO-8859-1, Windows-1252, or raw hex/base64 bytes when your source is binary.
Tick 'Prepend a BOM' only when reproducing a hash taken over a BOM-prefixed file, and 'Append a trailing newline' to match echo "text" | b2sum, which hashes an extra LF.
Switch on keyed mode to compute a BLAKE2b MAC: enter a key of up to 64 bytes as UTF-8 text, hex or base64, and watch the byte counter — an over-long key is rejected rather than truncated.
In file mode, drop a file onto the drop zone; the progress bar shows percentage and MB/s while the file is streamed through BLAKE2b in chunks, and changing the length or key re-hashes it.
Paste the expected digest into 'Compare against an expected hash' for a green match or red mismatch verdict — bare hex, base64, a b2sum line or a BSD BLAKE2b (file) = hash tag are all accepted.
Frequently Asked Questions
How do I generate and verify a BLAKE2b hash?
In text mode, type into the input box — the digest appears immediately and updates on every keystroke, with no Generate button to press. Set the output length first (1–64 bytes) and choose an input encoding if your source is not UTF-8, because the digest covers bytes, not characters. In file mode, drop a file in: it is read in 4 MiB chunks and fed through a streaming BLAKE2b implementation, so nothing is uploaded and nothing is held in memory in one piece. To verify, paste the digest you were given into the compare box; a whole b2sum line can be pasted unedited.
What is BLAKE2b, and is it a NIST standard?
No, and that distinction matters when a compliance rule names a hash. BLAKE2b is not standardised by NIST; it is specified in RFC 7693 (November 2015), an Informational RFC, and was published in 2012 by Jean-Philippe Aumasson, Samuel Neves, Zooko Wilcox-O'Hearn and Christian Winnerlein. Its ancestor BLAKE was one of the five finalists in NIST's SHA-3 competition, losing to Keccak in October 2012 — finalist, not winner. BLAKE2b is the variant tuned for 64-bit CPUs: 64-bit words, 12 rounds, 128-byte blocks, output of 1 to 64 bytes. Where FIPS 140 compliance is required, use SHA-2 or SHA-3 instead.
Is it safe to hash sensitive data or a MAC key here?
Yes. No browser implements BLAKE2b in the Web Crypto API, so this tool hashes with a WebAssembly module served from this site — not a third-party CDN script. Your input, your files and any key you type stay in the tab: nothing is uploaded, nothing is logged, nothing is stored. You can check that claim without trusting us: open DevTools, switch to the Network tab, hash a 2 GB file, and watch zero requests appear after the one-time WebAssembly fetch on first use. Nothing is sent when you change the length, the key or the input.
Is BLAKE2b faster than SHA-256, and when should I prefer it?
In pure software on a 64-bit CPU, yes — typically around two to three times SHA-256's throughput, because BLAKE2b was designed in 2012 for wide 64-bit registers while SHA-256 dates from 2001. But that comparison flips on hardware with SHA extensions: Intel SHA-NI and the ARMv8 crypto extensions accelerate SHA-256 in silicon and often put it ahead of BLAKE2b on the same machine. SHA-3 is generally slower than both in software. Choose BLAKE2b for throughput on machines you control or when you want its native keyed mode; choose SHA-256 for interoperability, FIPS compliance, or anywhere a published spec names it.
Why doesn't my BLAKE2b digest match another tool's?
Almost always a parameter, not the data. The output length is mixed into BLAKE2b's parameter block before any input is absorbed, so BLAKE2b-256 is not the first 32 bytes of BLAKE2b-512 — the two share no prefix at all. Libraries disagree on the default: libsodium's crypto_generichash defaults to 32 bytes, while b2sum and this tool default to 64. Use b2sum -l 256 to ask the CLI for a 32-byte digest. The other usual suspects are a key on one side only, BLAKE2s instead of BLAKE2b, a trailing newline from echo, and the optional salt/personalisation fields, which this tool leaves zero.
How is BLAKE2b's keyed mode different from HMAC-BLAKE2b?
BLAKE2b takes a key natively: a key of 1–64 bytes is written into the parameter block and absorbed as one padded 128-byte prefix block, producing a MAC in a single pass. HMAC (RFC 2104) instead wraps any hash in two nested calls, which costs extra compressions and exists because Merkle–Damgård hashes like SHA-256 are vulnerable to length extension. BLAKE2b is not, so the wrapper buys nothing. The two are different constructions and produce different tags — a keyed BLAKE2b value will never equal an HMAC-BLAKE2b value. libsodium's crypto_generichash is exactly this keyed mode. For RFC 2104 tags, use the [HMAC Generator & Verifier](/tools/hmac-generator-verifier/).
Where is BLAKE2b actually used in production?
Most widely as a building block rather than a headline hash. Argon2 — the password-hashing competition winner and current OWASP first choice — uses BLAKE2b for its variable-length hash and its compression function, so every Argon2id verification runs BLAKE2b internally; see the [Argon2 tool](/tools/argon2-hash-generator-verifier/). libsodium exposes it as crypto_generichash, the default 'hash some bytes' primitive in that library. GNU coreutils ships b2sum, making BLAKE2b-512 a first-class checksum on Linux. It is registered in the multiformats table for IPFS content addressing, and Zcash's Equihash proof-of-work is built on it.
Can I use BLAKE2b to hash passwords?
No. BLAKE2b is built for throughput — gigabytes per second on one core, and a GPU runs billions of guesses in parallel — which is exactly the property you do not want between an attacker and a user's password. Salting does not fix a fast hash. Use [Argon2id](/tools/argon2-hash-generator-verifier/) (which runs BLAKE2b internally but adds a memory-hard work factor), [bcrypt](/tools/bcrypt-hash-generator-verifier/) with cost 12 or more, [scrypt](/tools/scrypt-hash-generator-verifier/), or [PBKDF2](/tools/pbkdf2-hash-generator-verifier/) with 600,000+ iterations where FIPS forces your hand. If you were handed an unlabelled 128-hex-character digest, the [Hash Identifier](/tools/hash-identifier/) ranks candidates — BLAKE2b-512 is Hashcat mode 600.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.