Call the free BLAKE3 hash API endpoint
curl -X POST https://aisenseapi.com/services/v1/blake3_hash \
-H "Content-Type: application/json" \
-d '{"data":"Hello world"}'{"blake3_hash":"e7e6fb7d2869d109b62cdb1227208d4016cdaa0af6603d95223c6a698137d945"}Count the characters in that value and you get 64. That is 32 bytes, or 256 bits, the default BLAKE3 output. The digest is a constant: any correct BLAKE3 implementation returns those same characters for the eleven bytes of Hello world, and the official test vectors say the same about abc, which is 6437b3ac38465133ffb63b75273a8db548c558465d79db03fd359c6cd5bd9d85.
Raw bodies work too. Send the bytes as text/plain and you skip the business of escaping quotes and newlines into JSON. A file upload in a multipart field named file hashes the file's bytes the same way, up to 1 MiB; a larger file is refused with 413, because a file that size is hashed faster where it already is.
curl -X POST https://aisenseapi.com/services/v1/blake3_hash \
-H "Content-Type: text/plain" \
--data-binary "Hello world"{"blake3_hash":"e7e6fb7d2869d109b62cdb1227208d4016cdaa0af6603d95223c6a698137d945"}Both calls hash the same eleven bytes, so both return the same line. Trailing newlines are the classic trap. A shell echo quietly appends one, and that single extra byte rewrites every character of the digest.
Response fields
| Field | Type | Description |
|---|---|---|
| blake3_hash | string | Exactly 64 characters of lowercase hex. The length never varies with the input. An empty body is refused with HTTP 400 and a fix, like every endpoint in the family, and input over 1 MiB with 413. |
Input is treated as bytes. Text is hashed as UTF-8, so accented letters and emoji contribute their encoded bytes rather than any abstract code point. Nothing is trimmed or normalised before hashing.
What BLAKE3 changes
BLAKE2 came in two sizes and several variants; BLAKE3 is one algorithm. It takes the BLAKE2s compression function, cuts the rounds from ten to seven, and arranges the input as a Merkle tree of 1 KiB chunks. The tree is what makes it different in practice: chunks can be hashed on separate cores or with SIMD lanes at the same time, and the result is still one well-defined digest, so a library that hashes in parallel and one that hashes serially agree to the last character. The default output is 256 bits, and the same function also works as a keyed hash, a key derivation function and an extendable output function, none of which this endpoint exposes.
It is not a NIST standard and does not try to be. It is the hash you reach for when you want speed and a modern design, and it is what tools like b3sum, several package managers and content-addressed stores already use.
The same length as SHA-256, which is a trap for verifying
A BLAKE3 digest is 64 hex characters, exactly like SHA-256, SHA3-256 and BLAKE2b-256. Nothing in the string says which algorithm made it. The verify endpoint therefore wants the algorithm named for BLAKE3, and a 64 character hash sent without a name is read as SHA-256, compared, and reported as a mismatch with the SHA-256 value shown. That is honest, and it is also easy to misread as a bug. Name the algorithm.
Verify a digest, naming the algorithm
POST /hash_verify takes data, an expected hash and, for this algorithm, an algorithm field. The field is required here because a 64-character digest is also what SHA-256 produces, and without it the hash is read as that.
curl -X POST https://aisenseapi.com/services/v1/hash_verify \
-H "Content-Type: application/json" \
-d '{"data":"Hello world","hash":"e7e6fb7d2869d109b62cdb1227208d4016cdaa0af6603d95223c6a698137d945","algorithm":"blake3"}'{"match":true,"algorithm":"blake3","computed":"e7e6fb7d2869d109b62cdb1227208d4016cdaa0af6603d95223c6a698137d945"}The comparison runs in constant time, and computed comes back on a mismatch as well, so you see what your input really hashes to. The hash verify API endpoint page covers the full behaviour.
Do not store passwords this way
Common uses
Callers reach for the free BLAKE3 hash API endpoint in a handful of recurring situations.
Content addressing
Key a cache, a build artifact store or a deduplicating backup by digest. BLAKE3 was designed for exactly this load: large inputs, many of them, hashed as fast as the disk delivers them.
Checking a download
More and more release pages publish a b3sum beside the SHA-256. Hash the file here, or on your own machine for anything over 1 MiB, and compare.
Cross-implementation debugging
When your library and someone else's disagree about BLAKE3, hash the same input here. A third implementation turns an argument about code into a question about bytes.
A second fingerprint
Store a SHA-256 and a BLAKE3 digest side by side for a long-lived archive, so a future break in one design does not void the other.
Privacy and limits
The input travels in the POST body rather than the URL, so it never lands in a request path or a proxy access log. A hash is still not encryption, and your plaintext reaches this service before it is hashed. Keep genuinely confidential material inside your own process and use this service for testing, tooling and content you are happy to send.
The free BLAKE3 hash API endpoint shares the service-wide ceiling of 5000 requests per IP per day, and takes at most 1 MiB per call. It is computed by a separate hashing process, one computation at a time; on the rare occasion that process is busy or down the answer is 503 with a Retry-After, and a retry a second later goes through. No key, no account and no signup step stand in the way. Every route sits under the base URL https://aisenseapi.com/services/v1, and the whole catalogue is listed on Free public REST APIs.