b2KIT

BLAKE2 / BLAKE3 Hash Generator

Generate BLAKE2b, BLAKE2s, and BLAKE3 hashes for text or files. Compare speeds against SHA-256 in real time.

Tested tool guide Tested browser tools Checked August 16, 2026

What BLAKE2 / BLAKE3 Hash Generator does, with a checked example

BLAKE2b, BLAKE2s, and BLAKE3 are modern cryptographic hash functions, and this tool computes all three for whatever text or file you give it, with SHA-256 as a speed baseline. Hashing happens entirely in the browser: nothing is uploaded, so it is safe even for files you would not want to send anywhere. The common surprise is that these are not three versions of one algorithm. BLAKE2 is defined by RFC 7693, BLAKE3 by its own separate spec, and neither is a NIST standard in the way SHA-256 is.

Worked example

A concrete input and expected output from the current implementation.

Input

abc

Expected output

BLAKE2b-512: ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d17d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923
BLAKE2s-256: 508c5e8c327c14e2e1a72ba34eeb452f37458b209ed63a294d999b4c86675982
BLAKE3: 6437b3ac38465133ffb63b75273a8db548c558465d79db03fd359c6cd5bd9d85

"abc" is the canonical test input: RFC 7693 Appendix A publishes the BLAKE2b-512 and BLAKE2s-256 digests of "abc", and the BLAKE3 test suite publishes its digest of "abc", so any correct implementation must produce exactly these hex strings. Hex case is irrelevant, so the same values in uppercase match too.

How the result is produced

1

How the digests are computed

The selected algorithm reads the input as raw bytes - UTF-8 for typed text, file bytes as stored - and pushes them through a one-way compression function. BLAKE2b works on 64-bit words with a 1024-bit block and 12 rounds; BLAKE2s on 32-bit words with a 512-bit block and 10 rounds; both descend from the ChaCha permutation. BLAKE3 reuses the BLAKE2s compression function at 7 rounds inside a binary Merkle tree, so multi-core machines can hash chunks in parallel.

2

How the speed comparison works

The benchmark runs the same input through BLAKE2b, BLAKE2s, BLAKE3, and SHA-256 many times, entirely in-browser, and shows relative throughput. Read it as a comparison for your machine, not a universal figure: BLAKE3's tree structure only pays off beyond its 1 KiB chunk size and with multiple cores, while on short strings the four functions finish within a small factor of one another.

Good uses

  • Verifying a downloaded file against a BLAKE2 or BLAKE3 checksum the author published: hash the local copy and compare the hex strings.
  • Confirming that two files, or two pasted configuration snippets, are byte-identical without diffing - a single changed byte produces a completely different digest.
  • Choosing a hash for a script or pipeline with the live benchmark open: when throughput matters and nothing forces SHA-256, BLAKE3 usually wins on large data, while BLAKE2b offers RFC-standardized output.

Limits and checks

  • A digest does not hide its input. If the text is a common password or phrase, anyone can hash guesses and match your output, so treat these as integrity fingerprints, not password storage or encryption.
  • The exact bytes are what get hashed: a trailing newline, an extra space, or Windows CRLF line endings change the digest completely. The same visible text from two editors can hash differently, and file hashes only match when both copies are identical bytes.
  • BLAKE2 and BLAKE3 are not FIPS-approved like the SHA-2 family, and BLAKE3 has no RFC. In compliance-driven environments, faster does not make them interchangeable with SHA-256, so verify the applicable rules before swapping.

Common questions

Can I reverse the hash to get my text or file back?

No. These functions are one-way by design; the only way to recover an input from a digest is to guess candidates and hash each one, which only works for short, predictable values such as common passwords. If you need to get data back, store it encrypted or in a password manager instead of hashing it.

Which one should I use - is BLAKE3 always the best?

For new work without compliance constraints, BLAKE3 is a strong default: fastest on large inputs and a single 256-bit output. Choose BLAKE2b when you want an RFC-defined function with a 512-bit digest, and SHA-256 when you need NIST approval or maximum interoperability with existing tools.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools