BLAKE2s Hash Generator & Verifier
Generate and verify BLAKE2s hashes in your browser. Choose any output length from 1 to 32 bytes, use BLAKE2s's native keyed mode with a key up to 32 bytes, hash text as UTF-8/UTF-16/Latin-1/Windows-1252 or raw hex and base64, stream large files, and compare against an expected digest.
BLAKE2s and BLAKE2b are different hashes, even at the same length
Both are RFC 7693 and both can emit 32 bytes, but BLAKE2s works on 32-bit words with 10 rounds and 64-byte blocks while BLAKE2b uses 64-bit words, 12 rounds and 128-byte blocks — so BLAKE2s-256 never equals BLAKE2b-256. Add the output length and the optional key, both mixed into the parameter block before any input is absorbed, and you have the three things to check whenever a digest "should" match and does not.
Runs entirely in your browser. No browser exposes BLAKE2s 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. Device keys you paste here stay in the tab. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear after the one-time wasm fetch.
BLAKE2s-256 digest
0 bytes hashed — canonical empty-input digestFix the parameters above to see a digest.
Input
Any length from 1 to 32 bytes is legal — 32 is the hard ceiling of the 32-bit variant. The length is mixed into BLAKE2s's parameter block, so BLAKE2s-128 is not BLAKE2s-256 cut in half.
0 characters · 0 encoded bytes
UTF-8 is what Python's hashlib.blake2s, openssl dgst -blake2s256 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 coreutils-style hash filename line or a BSD BLAKE2S-256 (file) = hash tag all work. Only candidates of exactly 32 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 you were handed.
Do not store passwords or device PINs with BLAKE2s
BLAKE2s is fast on purpose — that is its entire reason to exist — and a fast hash is the wrong tool for any secret a human chose. A four-digit PIN hashed with BLAKE2s is enumerable in microseconds, salt or not. Use a deliberately slow, memory-hard function: Argon2id, bcrypt (cost ≥ 12), scrypt or PBKDF2. On a microcontroller that genuinely cannot afford a memory-hard KDF, do not store the secret on the device at all — keep the verification server-side.
Why two tools disagree about "the" BLAKE2s of your data
- • BLAKE2s vs BLAKE2b. The most common cause. Both are RFC 7693, both can produce 32 bytes, and a library that just says "blake2" may mean either.
- • A different output length. The length is part of the parameter block, so a 16-byte BLAKE2s digest is not the first half of the 32-byte one.
- • Keyed vs unkeyed. A key changes the parameter block as well as adding a prefix block; the two digests are unrelated.
- • Salt and personalisation. BLAKE2s also has optional 8-byte salt and personalisation fields. This tool leaves both zero, as do
openssland Python's defaults; a protocol that sets a personalisation string produces a different digest on purpose. - • A trailing newline or a BOM. Piping through
echoadds an LF, and a UTF-16 file from a Windows editor starts with two extra bytes.
Technical specifications
- • Algorithm: BLAKE2s (RFC 7693, 2015), derived from BLAKE — a finalist in NIST's SHA-3 competition. BLAKE2 itself is not a NIST standard.
- • Internals: 32-bit words, 10 rounds, 64-byte blocks, HAIFA-style counter, ChaCha-derived G function
- • Output: 1–32 bytes, chosen per digest and mixed into the parameter block (currently 32 bytes = 256 bits)
- • Keyed mode: native, key of 1–32 bytes padded to one 64-byte block and absorbed first — a MAC in one extra compression
- • Security: n/2-bit collision resistance and n-bit preimage resistance for an n-bit digest, so the 32-byte output matches SHA-256's security level; no known attacks on the full-round function
- • Length extension: not applicable — BLAKE2 finalises with a last-block flag, so
BLAKE2s(key ‖ message)is a sound MAC whereSHA-256(key ‖ message)is not - • Empty input: BLAKE2s-256 of zero bytes is
69217a3079908094e11121d042354a7c1f55b6482ca1a51e1b250dfd1ed0eef9 - • Engine: hash-wasm WebAssembly, 4 MiB streaming chunks for files
- • Not exposed here: the optional salt and personalisation fields and the BLAKE2sp tree variant
Common use cases
mac1/mac2 cookie fields — a MAC with no HMAC wrapper anywhere in the design.About BLAKE2s Hash Generator & Verifier
The BLAKE2s Hash Generator & Verifier computes BLAKE2s 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. BLAKE2s is the 32-bit member of BLAKE2 (RFC 7693): 32-bit words, 10 rounds, 64-byte blocks, output of 1 to 32 bytes and an optional key of up to 32 bytes. It is the variant chosen by protocols that have to run on small hardware — WireGuard and the Linux kernel's random-number generator among them — and both of its parameters are exposed here, because a BLAKE2s digest is only reproducible when both sides agree on them.
Why use a BLAKE2s Hash Generator & Verifier?
BLAKE2s is the variant people reach for when a digest has to be produced by a microcontroller and verified by a server, which makes cross-implementation mismatches common — and most online tools give you no way to diagnose one. This tool shows the output length and the key explicitly, rejects an over-long key with a clear message instead of truncating it, streams files in 4 MiB chunks so nothing large enters memory at once, allows empty input so the canonical zero-byte digest is readable, and states which format it compared: hex case-insensitively, base64 case-sensitively, because base64 is case-significant.
Who is it for?
Firmware and IoT developers reproducing a device-side digest on the desktop, WireGuard and Noise implementers checking a handshake hash or a mac1 tag, kernel and embedded engineers comparing BLAKE2s against SHA-256 on 32-bit targets, and anyone holding a 64-hex-character digest that a BLAKE2b tool refuses to reproduce.
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 32, which is BLAKE2s's hard ceiling. Presets cover 8, 16, 20, 28 and the 32-byte default.
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 69217a30…0eef9.
Pick the input encoding — UTF-8 (the default), UTF-16LE/BE, ISO-8859-1, Windows-1252, or raw hex/base64 when you are hashing a packet, a device ID or a firmware header.
Tick 'Prepend a BOM' only when reproducing a hash over a BOM-prefixed file, and 'Append a trailing newline' to match a digest taken over echo output, which adds an LF byte.
Switch on keyed mode for a BLAKE2s MAC: enter a key of up to 32 bytes as UTF-8 text, hex or base64 and watch the byte counter — an over-long key is rejected, never silently truncated.
In file mode, drop a file onto the drop zone; the progress bar shows percentage and MB/s while it is streamed through BLAKE2s, 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 hash-plus-filename line or a BSD BLAKE2S-256 (file) = hash tag all work.
Frequently Asked Questions
How do I generate and verify a BLAKE2s 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 (1–32 bytes) and choose an input encoding if your source is not UTF-8, since the digest covers bytes rather than characters; for a device ID or a packet, switch to 'Hex bytes' so the decoded bytes are hashed instead of the hex text. In file mode, drop a file in and it is streamed through BLAKE2s in 4 MiB chunks. To verify, paste the digest you were given into the compare box and read the verdict.
What is BLAKE2s, and is it a NIST standard?
No. BLAKE2s 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 a finalist — not the winner — in NIST's SHA-3 competition, which Keccak won in October 2012. BLAKE2s is the 32-bit-word variant: 10 rounds, 64-byte blocks, at most 32 bytes of output and at most a 32-byte key, sized so the whole state fits comfortably on small hardware. If a compliance rule requires a NIST-approved hash, use SHA-2 or SHA-3 instead.
BLAKE2s vs BLAKE2b — which one should I use?
Match the word size to the platform. BLAKE2b uses 64-bit words and is faster on any 64-bit CPU — servers, desktops, phones — and can output up to 64 bytes. BLAKE2s uses 32-bit words and wins on 32-bit targets such as ARM Cortex-M, where 64-bit rotations decompose into several instructions, and its 64-byte block and smaller state fit a tighter RAM budget. Security is equivalent at equal output length. The practical trap: they are different functions, so BLAKE2s-256 never equals BLAKE2b-256 even though both are 64 hex characters. Interoperating with an existing protocol? Use whichever it specifies.
Is it safe to hash sensitive data or a device key here?
Yes. No browser exposes BLAKE2s through the Web Crypto API, so this tool hashes with a WebAssembly module served from this site rather than a third-party CDN script. Input, files and any key you type stay in the tab — nothing is uploaded, logged or stored. Verify it without trusting us: open DevTools, switch to the Network tab, hash a large file and watch zero requests appear after the one-time WebAssembly fetch. That said, treat a production device key like a production secret: prefer a throwaway key when you only need to check that two implementations agree.
Why doesn't my BLAKE2s digest match another implementation's?
Check the parameters before the data. The output length is mixed into BLAKE2s's parameter block, so a 16-byte digest is not the first half of the 32-byte one. A key changes the parameter block as well as prefixing a block, so keyed and unkeyed digests are unrelated. BLAKE2b is the other classic cause — same RFC, same 32-byte output option, completely different result. BLAKE2s also has optional 8-byte salt and personalisation fields, which this tool leaves zero and some protocols deliberately set. Finally, a trailing newline from echo or a BOM from a Windows editor changes the input bytes.
Can I use BLAKE2s as a MAC instead of HMAC?
Yes — that is one of its design goals. A key of 1–32 bytes goes into the parameter block and is absorbed as one padded 64-byte prefix block, so a MAC costs one extra compression instead of HMAC's two full passes. WireGuard does exactly this: keyed BLAKE2s produces the mac1 and mac2 fields in its handshake, with no HMAC wrapper anywhere in the design. Note the tag is not HMAC-BLAKE2s and will never equal one. HMAC exists to protect Merkle–Damgård hashes from length extension; BLAKE2 finalises with a last-block flag and is immune. For RFC 2104 tags, use the [HMAC Generator & Verifier](/tools/hmac-generator-verifier/).
Where is BLAKE2s actually used?
WireGuard is the best-known user: BLAKE2s is its hash and keyed BLAKE2s its MAC. The Linux kernel's random-number generator has used BLAKE2s since version 5.17, replacing SHA-1. The Noise Protocol Framework offers it alongside BLAKE2b and SHA-256, and it is common in firmware, sensor authentication and other 32-bit environments. One correction worth making, because it circulates widely: Argon2 always uses BLAKE2b internally, on every platform — there is no 32-bit Argon2 variant that switches to BLAKE2s. See the [Argon2 tool](/tools/argon2-hash-generator-verifier/) for what Argon2 actually does.
Can I use BLAKE2s to hash passwords or PINs?
No. BLAKE2s is fast by design, which is the opposite of what a human-chosen secret needs: a four-digit PIN is enumerable in microseconds and a common password falls just as fast, salt or no salt. Use a deliberately slow, memory-hard function: [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. On a microcontroller that genuinely cannot afford a memory-hard KDF, keep verification server-side instead. Handed an unlabelled 64-hex digest? The [Hash Identifier](/tools/hash-identifier/) ranks the candidates — BLAKE2s, BLAKE3, SHA-256 and SHA3-256 all look identical.
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.