BLAKE3 Hash Generator & Verifier
Generate and verify BLAKE3 hashes in your browser. Pick any extendable output length, switch on keyed_hash mode with a 32-byte key, hash text as UTF-8/UTF-16/Latin-1/Windows-1252 or raw hex and base64, stream large files with live progress, and compare against a b3sum checksum.
Longer BLAKE3 output does not mean more security
BLAKE3 claims 128-bit security in every mode, whatever length you ask for. Extra output extends the keystream — a 64-byte BLAKE3 digest literally begins with the 32-byte one — but it does not raise the security level, because the tree's chaining values are 256 bits wide. That is the opposite of BLAKE2, where the length is mixed into the state and BLAKE2b-512 really is stronger than BLAKE2b-256. Use the XOF for key material and fingerprint sizes, not for extra margin.
Runs entirely in your browser. No browser exposes BLAKE3 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. The random-key button uses your browser's own crypto.getRandomValues. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear after the one-time wasm fetch.
BLAKE3-256 digest
0 bytes hashed — canonical empty-input digestFix the parameters above to see a digest.
Input
BLAKE3 is an extendable-output function: longer output continues the same keystream, so the 32-byte digest is a prefix of every longer one. The algorithm has no length limit at all; this tool stops at 1024 bytes to keep the page responsive. Extra bytes do not add security — see the note below.
0 characters · 0 encoded bytes
UTF-8 is what b3sum, the Rust blake3 crate 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 or a b3sum line (hash filename) all work. Only candidates of exactly 32 bytes are considered; if you pasted a 32-byte digest while asking for 64 bytes of output, shorten the length instead of trusting the verdict.
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 — four of the five are 64 hex characters long and none of them agree, which is exactly why a bare digest cannot be identified by shape.
BLAKE3 is the worst possible password hash
Being the fastest hash here is exactly what disqualifies it: every gigabyte per second of throughput is a gigabyte per second of guessing for an attacker with your database, and BLAKE3's tree structure parallelises across GPU cores beautifully. Salting does not fix a fast hash. Use a deliberately slow, memory-hard function: Argon2id, bcrypt (cost ≥ 12), scrypt or PBKDF2. BLAKE3 belongs in checksums, content addressing and key derivation from already-high-entropy secrets.
Why two tools disagree about "the" BLAKE3 of your data
- • The wrong mode. BLAKE3 has three:
hash,keyed_hashandderive_key. Each uses different domain-separation flags, so the same input and key give three unrelated outputs. - • A different output length. Because the XOF is prefix-consistent, a 32-byte digest and a 64-byte one agree on their first 32 bytes — so a comparison can be "half right" and still fail.
- • It is not BLAKE2. BLAKE3 shares BLAKE2s's round function but not its output: BLAKE3-256 never equals BLAKE2s-256.
- • A trailing newline or a BOM.
echo "abc" | b3sumhashes 4 bytes, not 3. - • Hex vs text. Hashing the string
deadbeefis not the same as hashing the four bytes it represents — switch the input encoding to "Hex bytes".
Technical specifications
- • Algorithm: BLAKE3, published January 2020 by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves and Zooko Wilcox-O'Hearn. It is not a NIST standard and has no RFC — it is a specification plus a reference implementation.
- • Internals: BLAKE2s's G function reduced from 10 rounds to 7, 32-bit words, 64-byte compression blocks, 1 KiB chunks arranged in a binary Merkle tree
- • Parallelism: the tree is what makes BLAKE3 SIMD- and thread-friendly and enables verified streaming; the gain applies to long inputs, not to short ones
- • Output: extendable (XOF) and unbounded; this tool offers 1–1024 bytes, currently 32 bytes = 256 bits
- • Security claim: 128 bits in all modes and at all output lengths — unlike BLAKE2, longer output does not increase it
- • Modes:
hash,keyed_hash(exactly 32 bytes of key) andderive_key(context-string KDF, not exposed by this tool's WebAssembly build) - • Empty input: BLAKE3-256 of zero bytes is
af1349b9f5f9a1a6a0404dea36dcc9499bcb25c9adc112b7cc9a93cae41f3262 - • Engine: hash-wasm WebAssembly, single-threaded, 4 MiB streaming chunks for files
- • Length extension: not applicable — the root node is finalised with a ROOT flag, so
BLAKE3(key ‖ message)is a sound MAC
Common use cases
b3sum over large media files, container layers and scientific datasets, where the tree mode lets several cores work on one file.0x1e, and used by build tools and content stores that want fingerprints faster than SHA-256.derive_key mode with a hard-coded context string turns one high-entropy secret into many purpose-specific keys — a KDF for key material, never for passwords.keyed_hash with a 32-byte random key as a MAC, where you control both sides and do not need HMAC-SHA256 interoperability.About BLAKE3 Hash Generator & Verifier
The BLAKE3 Hash Generator & Verifier computes BLAKE3 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. BLAKE3 was published in 2020 as a redesign of BLAKE2s: the round function is cut from ten rounds to seven and the input is split into 1 KiB chunks arranged in a binary Merkle tree, which is what makes it SIMD- and thread-parallel and enables verified streaming. It is also an extendable-output function, so the digest length is a free parameter, and it has a keyed mode that takes exactly 32 bytes of key.
Why use a BLAKE3 Hash Generator & Verifier?
BLAKE3's two headline features are also its two most common sources of confusion, and this tool surfaces both. The output is a prefix-consistent keystream — a 64-byte digest literally begins with the 32-byte one — and extending it does not raise the security level, which stays at BLAKE3's claimed 128 bits in every mode. The key is exactly 32 bytes, not 'up to' 32, so a passphrase is not a valid key; the byte counter says so instead of letting you generate a digest nobody else can reproduce. Files stream in 4 MiB chunks, empty input is allowed, and the comparison tells you which format it used and why.
Who is it for?
Engineers adopting b3sum for large-file checksums, Rust and Go developers reproducing a blake3 crate or library value in the browser, content-addressed-storage and build-cache authors choosing a fingerprint length, protocol designers weighing keyed BLAKE3 against HMAC-SHA256, and anyone holding a 64-hex-character digest that could equally be SHA-256, BLAKE2s or BLAKE3.
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. BLAKE3 is an XOF with no algorithmic limit; the presets cover 16, the 32-byte b3sum default, 64, 128 and 1024 bytes of keystream.
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 af1349b9…f3262.
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 over a BOM-prefixed file, and 'Append a trailing newline' to match echo "text" | b3sum, which hashes an extra LF byte.
Switch on keyed mode for a BLAKE3 MAC: paste exactly 32 bytes of key as hex, base64 or UTF-8, or press 'Random key' to generate 32 bytes with your browser's own crypto.getRandomValues.
In file mode, drop a file onto the drop zone; the progress bar shows percentage and MB/s while the file is streamed through BLAKE3, 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 — a bare hex digest, base64, or a whole b3sum line can be pasted unedited.
Frequently Asked Questions
How do I generate and verify a BLAKE3 hash?
In text mode, type into the input box — the digest appears immediately and updates on every keystroke, with no Generate button. Set the output length first (32 bytes matches b3sum's default) 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 BLAKE3 implementation, so nothing is uploaded and the file is never held in memory in one piece. To verify, paste the digest you were given into the compare box — a whole b3sum line works unedited.
What is BLAKE3, and is it a NIST standard?
No — and unlike BLAKE2 it does not even have an RFC. BLAKE3 was published in January 2020 by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves and Zooko Wilcox-O'Hearn as a specification plus a reference implementation in Rust and C. Its lineage runs back through BLAKE2s to BLAKE, a finalist in NIST's SHA-3 competition that lost to Keccak in October 2012, so nothing in the family is NIST-standardised. Internally it is BLAKE2s's round function reduced from ten rounds to seven, with the input split into 1 KiB chunks and combined in a binary Merkle tree. Where FIPS compliance matters, use SHA-2 or SHA-3.
Is BLAKE3 really faster than SHA-256 and BLAKE2?
On long inputs, yes, and by a wide margin — but the headline figures come from the conditions BLAKE3 was designed for. Single-threaded with SIMD it is typically several times faster than BLAKE2b and much faster than software SHA-256; with multiple threads the tree structure lets throughput scale across cores, which no Merkle–Damgård hash can do. Two caveats keep the comparison honest: on CPUs with SHA-NI or ARMv8 crypto extensions, hardware-accelerated SHA-256 is far more competitive, and on short inputs — under one 1 KiB chunk — there is no tree to parallelise and BLAKE3 performs much like BLAKE2s. This browser build is single-threaded.
Is it safe to hash sensitive data or a key here?
Yes. No browser implements BLAKE3 in the Web Crypto API, so this tool hashes with a WebAssembly module served from this site rather than a third-party CDN script. Your input, your files and any key you type stay in the tab: nothing is uploaded, logged or stored. The 'Random key' button uses your browser's own crypto.getRandomValues, not a server. Verify it 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.
Does a longer BLAKE3 output give more security?
No, and this is the most common misunderstanding about the algorithm. BLAKE3 claims 128-bit security in every mode and at every output length, because its chaining values are 256 bits wide; asking for 64 bytes instead of 32 does not add margin. The extra bytes come from extending the same keystream, so a 64-byte BLAKE3 digest literally begins with the 32-byte one — useful, and the opposite of BLAKE2, where the length is mixed into the state and BLAKE2b-512 genuinely is stronger than BLAKE2b-256. Use the XOF to size key material or fingerprints, not to buy security.
How does BLAKE3's keyed mode work, and what about derive_key?
BLAKE3 has three modes, each with its own domain-separation flags: plain hash, keyed_hash, and derive_key. keyed_hash loads the key as the tree's initial chaining value, which is why it is exactly 32 bytes — not 'up to' 32 — and why a passphrase is not an acceptable key; use 32 random bytes. The result is a MAC with no HMAC wrapper, since BLAKE3 is not vulnerable to length extension. derive_key is a KDF that takes a hard-coded context string and turns one high-entropy secret into many purpose-specific keys; this tool's WebAssembly build does not expose it, so it is not offered here rather than being faked.
Where is BLAKE3 used, and when should I pick it over SHA-256?
b3sum is the reference CLI and the usual entry point for large-file checksums. Bao uses BLAKE3's Merkle tree for verified streaming, authenticating a download incrementally and extracting verifiable slices — something a sequential hash cannot do. BLAKE3 is registered in the multiformats table as multihash code 0x1e, and build caches and content-addressed stores adopt it for fingerprints that outpace SHA-256. Choose it for bulk hashing and content addressing inside systems you control. Stay on SHA-256 for TLS certificates, JWT signing, Bitcoin, Git, FIPS-regulated work, or anywhere a published specification names it.
Can I use BLAKE3 to hash passwords?
No — it is the worst choice in this catalogue for that job, precisely because it is the fastest. Every gigabyte per second of throughput is a gigabyte per second of guessing for an attacker holding your database, and the tree structure parallelises across GPU cores beautifully. Salting does not fix a fast hash. Use [Argon2id](/tools/argon2-hash-generator-verifier/), [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. Handed an unlabelled 64-hex-character digest? BLAKE3, BLAKE2s, SHA-256 and SHA3-256 are indistinguishable by shape — the [Hash Identifier](/tools/hash-identifier/) ranks the candidates.
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.