BLAKE3 Hash Generator

The fastest general-purpose hash in existence, running inside your browser via WebAssembly. Hash text, hex strings, base64, or full files at gigabytes per second — with zero uploads.

Input

Output

Or drop a file to compute its BLAKE3 digest

Drag & drop · up to 64 MB · solved locally

BLAKE3 hash

Loading the BLAKE3 engine… (WebAssembly, first run only)

Why BLAKE3 is different

BLAKE3 builds on the ChaCha quarter-round and parallelizes it across bytes with an inner Merkle tree. The result: on a single modern core it hashes about ten to twenty times faster than SHA-256, and it scales linearly as you add threads.

The WebAssembly build this page loads brings that same engine into your browser, so hashing a 64 MB file takes a fraction of a second — entirely on your device.

What to use it for

Content-addressed storage & object deduplication
High-throughput file integrity checks at scale
Streaming checksums of very large inputs
Fast in-memory fingerprinting for caches and indexes

Storing passwords? BLAKE3 is far too fast. Use bcrypt or Argon2id instead.

Code snippets

Generate BLAKE3 in your language

Every implementation below prints the identical 256-bit digest for the same bytes — lowercase hex, fully deterministic. Confirm it by pasting the same input into the tool above:

// npm i @noble/hashes
import { blake3 } from "@noble/hashes/blake3";
import { bytesToHex } from "@noble/hashes/utils";

const input = new TextEncoder().encode("hello world");
console.log(bytesToHex(blake3(input)));
// d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24

# pip install blake3
from blake3 import blake3

print(blake3(b"hello world").hexdigest())
# d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24

// go get github.com/zeebo/blake3
package main

import (
    "encoding/hex"
    "fmt"

    "github.com/zeebo/blake3"
)

func main() {
    sum := blake3.Sum256([]byte("hello world"))
    fmt.Println(hex.EncodeToString(sum[:]))
    // d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24
}

// cargo add blake3
use blake3::Hasher;

fn main() {
    let mut hasher = Hasher::new();
    hasher.update(b"hello world");
    println!("{}", hasher.finalize().to_hex());
    // d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24
}

<?php
// composer require kornrunner/blake3
use kornrunner\Blake3\Blake3;

echo Blake3::hash("hello world") . PHP_EOL;
// d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24

# Install the official CLI: cargo install b3sum
printf 'hello world' | b3sum
# d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24  -

BLAKE3 has no match in PHP's built-in hash() (as of PHP 8.4), so the snippet uses the kornrunner/blake3 package. On the command line, b3sum is the reference CLI maintained by the BLAKE3 team.

Algorithm guide

BLAKE3 explained

By Mohit Singh · ~2,096 words · Reviewed September 2026

What is BLAKE3?

BLAKE3 is a cryptographic hash function that takes input of arbitrary length and produces a fixed 256-bit (32-byte) digest. It is the direct successor to BLAKE2 — itself a finalist in the Password Hashing Competition and the hash behind many Linux kernels and Argon2 — and it reuses the hardened ChaCha stream-cipher quarter-round as its core mixing function.

What sets BLAKE3 apart from SHA-256 is architecture, not just numbers. Instead of processing input strictly one block after another, BLAKE3 arranges blocks into an inner Merkle tree. That single design decision delivers three properties at once: it parallelizes naturally across CPU cores, it makes SIMD (single-instruction multiple-data) vectorization effective on each core, and it enables the same tree to serve as a streaming hash, a content-addressed tree hash, an extensible output function, a MAC, and a KDF. No other mainstream hash spans that range with one primitive.

Sizing it up against the other tools on this site: MD5 returns 128 bits, SHA-256 returns 256 bits and nothing else, while BLAKE3 defaults to 256 bits but can stretch from 1 byte up to its 2⁶⁴−1-byte limit. That flexibility, plus the speed, is the main argument for choosing BLAKE3 in a new system.

Where BLAKE3 came from

The lineage starts in 2012 with BLAKE, a SHA-3 finalist designed by Jean-Philippe Aumasson and others. Its revised form, BLAKE2, was published in 2013 and became the default hash in many systems, including Debian, OpenSSL, libsodium, and the Linux kernel's hmac infrastructure. BLAKE2 set a benchmark for speed on 64-bit hardware, but its sequential structure still limited multi-core scaling.

BLAKE3 was finalized in January 2020 by Jack O'Connor, Jean-Philippe Aumasson, Samuel Neves, and Zooko Wilcox-O'Hearn. It abandons that sequential structure entirely: every chunk of the message is processed in parallel, with a binary tree folding chunk digests into a single root. Since its 1.0 release the reference implementation has been audited and adopted by projects like IPFS, Storj, Wasmer, and nix, and the algorithm has withstood sustained public cryptanalysis. It is one of the youngest widely-deployed hashes — and one of the fastest ever built.

That lineage matters for trust. BLAKE was heavily analyzed as a SHA-3 candidate, so the core permutation predates BLAKE3 by well over a decade of public cryptanalysis. The BLAKE3 team reused it rather than inventing a new one, which is why the early independent audits concentrated on the tree layer — the only genuinely new part — and found that the advertised security bounds hold.

Inside the Merkle tree

BLAKE3 splits the message into 1024-byte chunks. Each chunk is processed by a compression function built from the ChaCha quarter-round, producing a 32-byte chunk hash. A binary tree then combines pairs of chunk hashes level by level until a single 256-bit root digest remains.

This tree is what makes BLAKE3's streaming behavior so clean. With a huge input you do not need to know the total length in advance: each new chunk is folded into the tree as it arrives, and the root digest is recomputed along the path to the root. The cost of that bookkeeping is logarithmic, so hashing a 1 gigabyte file is essentially as cheap as hashing a 1 megabyte file multiplied by the byte count.

The compression function itself is a tweaked version of BLAKE2s, itself derived from BLAKE and ChaCha. Reusing a battle-tested primitive rather than inventing a new permutation is a deliberate conservatism: the security argument rests on components the community has analyzed for over a decade.

Inside each compression call, a set of flag bits tells the function which part of the tree it is compressing — whether a block opens or closes a chunk, whether the node is the root, and whether the run is a keyed or derive-key invocation. The flags are what make it safe to fold the same stream of bytes into a tree without ambiguity: the root digest can never be mistaken for a chunk digest, and each mode's output lives in its own domain.

Why it is so fast

Benchmark numbers depend on hardware, but the relative story is consistent. On a single modern x86 core with AVX2, BLAKE3 hashes roughly 2 to 4 GiB/s, versus 200 to 400 MiB/s for SHA-256. That is a tenfold to twentyfold advantage on one core alone.

Two techniques create the gap. First, the ChaCha quarter-round is extremely SIMD-friendly: four independent lanes can be processed with a single 128-bit instruction, and AVX-512 widens that further. Second, the Merkle tree lets independent chunks run on different cores with zero contention. In the reference Rust implementation, multithreaded hashing scales near-linearly, so a 64-core server can push hundreds of GiB/s.

Rough throughput on a modern desktop CPU, to set expectations:

BLAKE3, single core with AVX2 — roughly 1–4 GiB/s, the fastest of any mainstream hash.
BLAKE3, multithreaded — scales with core count; the reference implementation reaches hundreds of GiB/s on large servers.
SHA-256 — a few hundred MiB/s in plain software, up to a couple GiB/s with CPU SHA extensions.
MD5 — hundreds of MiB/s, roughly comparable to software SHA-256, a reminder that its speed alone never made it suitable for security.

For short inputs — a few kilobytes or less used by this tool — the absolute numbers are microseconds either way, which is why the "speed" of a web generator is mostly about not rounding-trip a server. The BLAKE3 speed advantage matters when you hash a lot of data: startup packages, image layers, storage objects, or a build cache re-verified a million times a day.

Security properties

BLAKE3 targets the same security levels as SHA-256: collision resistance of 128 bits (half of the 256-bit output, per the birthday bound), and preimage resistance of 256 bits. No practical attack against either has been published since the algorithm's release, and its compression function is derived directly from ChaCha and BLAKE2, both extensively analyzed.

A useful property of the tree design is that it does not weaken the fingerprints: every chunk is still compressed through a keyed, differencing input-tuned function, and the root digest is computed in a way that binds to the entire message and its length. Cryptanalysts have also studied the "tree speed-up" — whether parallelism lets an attacker search for collisions faster — and the answer is no: the birthday-bound security holds regardless of how many cores produce the digest.

Do not confuse "fast" with "suitable for passwords." BLAKE3's speed is exactly what makes it wrong for password storage: an attacker checking billions of BLAKE3 digests per second would crack leaked hashes almost instantly. Password hashing exists to be slow — use bcrypt or Argon2id, whose deliberately expensive parameters are the entire point.

Output sizing and modes

The default BLAKE3 output is 256 bits, but the algorithm is an extensible-output function (XOF): you can request as many bytes as you need, up to a cryptographic limit of 2⁶⁴ −1 bytes. A 512-bit or 1024-bit digest is simply the same tree's root expanded. In practice, BLAKE3 also ships two extra modes:

Keyed mode — a fast, well-defined MAC. Both parties share a 256-bit key; the output cannot be produced without it, which makes BLAKE3 a drop-in replacement for HMAC in high-throughput systems.
derive_key mode — a domain-separated KDF context. It is intended for deriving keys from high-entropy secrets (not for password hashing, which still needs Argon2id or bcrypt).

In practice, the default 256-bit output is the right choice unless you know otherwise. Going shorter weakens birthday resistance; going longer adds length without meaningful security gains for most applications. Because the extension is a pure function of the same tree, you can always derive a longer output later without re-generating data — keep the default and extend only if a protocol explicitly demands it.

Real-world use cases

Where does BLAKE3 actually get used in production? Content-addressed storage is the flagship: IPFS, Storj, and several object stores identify files by their BLAKE3 digest so that identical data can be stored once and verified cheaply. The tree structure also enables proofs of inclusion for individual chunks — a client can prove that a chunk belongs to a file without downloading the whole object.

The second big cluster is tooling. Package managers and CI systems use BLAKE3 for fast integrity checks of downloaded artifacts. Build caches and deduplication engines fingerprint millions of small objects per day, where per-hash latency compounds into minutes saved. Multimedia pipelines hash frames in parallel. For any of these, the same 256-bit security you expect from SHA-256 comes with a measurable throughput win.

A growing use is content-defined chunking in backup and sync tools. Rather than hashing whole files, these tools split data at content-dependent boundaries and hash the chunks independently; the Merkle structure that BLAKE3 already provides makes it cheap to compare two large datasets that differ only slightly, because only the changed branches of the tree differ.

BLAKE3 in the browser

There is a catch with BLAKE3 today: the Web Crypto API standardizes only SHA-1 and the SHA-2 family, so no browser exposes crypto.subtle.digest("BLAKE3"). Any browser-side BLAKE3 must run through a WebAssembly or pure-JS implementation. This page uses hash-wasm, a WebAssembly build of the reference implementation, compiled to a 23 KB bundle that is cached after its first load.

The practical consequence is that BLAKE3-in-the-browser is slightly heavier on first page load than SHA-256, and slightly lighter on every hash afterwards, because the WASM module handles potentially gigabytes of input without the browser's per-call overhead. For a web tool, the privacy story stays identical to SHA-256: the bytes never leave the device, and the digest is produced locally.

Because the algorithm is deterministic, you can cross-check it offline: b3sum on any machine, the snippets below, and this page all produce the same hex for the same bytes. That is the property that lets developers trust browser tooling at all — an online calculator would otherwise be a black box.

When not to use BLAKE3

BLAKE3 is not the right hammer for every nail. If your ecosystem already verifies against SHA-256 — TLS certificate signatures, most package managers, regulatory checklists — stick with SHA-256; the digest values must match what the system expects. If you are signing data, BLAKE3 is not a signature: you still need an asymmetric scheme over the digest. And for password storage, BLAKE3's raw speed is precisely the problem.

There is also the compatibility argument. SHA-256 exists in every library and hardware accelerator on Earth; BLAKE3 needs a dependency in most stacks (the PHP core is a notable holdout). When interoperability matters more than throughput, the standard should win. BLAKE3 shines when you control both ends of the pipeline.

How this tool works

WebAssembly core. The page imports hash-wasm, a WASM build of the reference BLAKE3 implementation. Everything runs in your browser.
UTF-8 by default. Text is encoded as UTF-8 before hashing, matching how b3sum and the reference API treat a byte string. Hex and base64 input modes decode the exact bytes you provide.
Debounced live hashing. As you type, the input is re-hashed after a 160 ms pause — the output and the per-run timing update together without jank.
File support. Drop a file and it is read via File.arrayBuffer(), hashed in one pass, and reported with its byte count. Files up to 64 MB are accepted.
Zero uploads. The page, fonts, and WASM binary are all same-origin static assets. Your input never appears in a network request — an improvement you can verify in DevTools.

Worked examples

Type these into the tool above and confirm the outputs match known values. The empty string's BLAKE3 digest is af1349b9f5f9a1a6a0404dea36dcc9499bcb25c9adc112b7cc9a93cae41f3262. The famous quick-brown-fox sentence produces 2f1514181aadccd913abd94cfa592701a5686ab23f8df1dff1b74710febc6d4a. And the hello, world string — with the comma and space exactly as usual — produces a1a55887535397bf461902491c8779188a5dd1f8c3951b3d9cf6ecba194e87b0. A fourth handy reference point is the plain string hello world, which hashes to d74981efa70a0c880b8d8c1985d075dbcbf679b99a5f9914e5aaf96b831a9e24.

The last three are worth an extra look. A one-character difference anywhere in the input changes every byte of the output, so these pairs are a fast sanity check that the implementation you are using is wired correctly. Any implementation, in any language, must produce the identical hex — BLAKE3 is fully deterministic.

If you want to exercise multi-block hashing rather than a short input, try a string that crosses the 1024-byte chunk boundary — for example a repeated 2,048 times. That exercises the tree layer (root, parent, and chunk folds), so it is the classic test when reviewing a pull request in a library that implements BLAKE3 for the first time.

Frequently asked questions

What is a BLAKE3 hash?

BLAKE3 is a cryptographic hash function finalized in 2020. It produces a 256-bit digest, provides 128-bit collision resistance, and is one to two orders of magnitude faster than SHA-256 through a Merkle-tree parallelization of the ChaCha quarter-round.

Is BLAKE3 secure?

Yes. BLAKE3 was designed by the BLAKE2 team (the PHC finalist) using the ChaCha core, and has received extensive third-party cryptanalysis since 2020 with no practical attacks. Its security targets are the same as SHA-256: 128-bit collision and 256-bit preimage resistance.

How is BLAKE3 different from SHA-256?

Both output 256 bits and have the same security margin. BLAKE3 is dramatically faster — roughly 10 to 20 times faster than SHA-256 on a single core via SIMD, and it scales linearly across cores. SHA-256 remains more widely supported because it is built into the Web Crypto API and every standard library.

Why isn't BLAKE3 in the Web Crypto API?

The Web Crypto API standardizes SHA-1 and the SHA-2 family only. BLAKE3 is too new and too fast-moving to be standardized there. This page loads a WebAssembly build instead, so you still get the full BLAKE3 even though no browser ships it natively.

Can BLAKE3 be used for password storage?

No. BLAKE3 is far too fast — an attacker can compute billions of hashes per second on a GPU. Password storage requires a deliberately slow, salted key-derivation function such as Argon2id or bcrypt. Use BLAKE3 for integrity and content addressing, never for passwords.

Is BLAKE3 suitable for very large files?

Yes, and that is one of its strengths. Its inner Merkle tree never has to wait for the whole input sequentially, so it can hash streams, parallelize across cores, and even produce a digest mid-stream — all inside your browser thanks to WebAssembly.

Other hash tools

MD5

Legacy checksums & fingerprints.

Open →

SHA-256

Fast, secure integrity hashing.

Open →

bcrypt

Salted, cost-tunable password hashing.

Open →

Argon2id

The current recommended password KDF.

Open →

Compare

All five algorithms side-by-side.

Open →