Call the free BLAKE2b hash API endpoint
curl -X POST https://aisenseapi.com/services/v1/blake2b_hash \
-H "Content-Type: application/json" \
-d '{"data":"Hello world"}'{"blake2b_hash":"a21cf4b3604cf4b2bc53e6f88f6a4d75ef5ff4ab415f3e99aea6b61c8249c4d0"}Count the characters in that value and you get 64. That is 32 bytes, or 256 bits. The digest is a constant: any correct BLAKE2b implementation returns those same characters for the eleven bytes of Hello world.
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.
curl -X POST https://aisenseapi.com/services/v1/blake2b_hash \
-H "Content-Type: text/plain" \
--data-binary "Hello world"{"blake2b_hash":"a21cf4b3604cf4b2bc53e6f88f6a4d75ef5ff4ab415f3e99aea6b61c8249c4d0"}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 |
|---|---|---|
| blake2b_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. |
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.
A 32 byte BLAKE2b, not half of a 64 byte one
BLAKE2b takes its output length as a parameter, from 1 to 64 bytes, and the length is mixed into the initial state. A 32 byte BLAKE2b is therefore its own hash: it is not the first 64 hex characters of the 64 byte BLAKE2b-512 digest, and the two never match. This endpoint computes the 32 byte form, BLAKE2b-256, with no key, no salt and no personalisation, which is what libsodium's crypto_generichash gives with default parameters and a 32 byte output.
If your library is producing the 64 byte digest, or a keyed one, its values will disagree with this service. Set the output length to 32 and leave the key empty before you compare.
BLAKE2 came out of the SHA-3 competition finalist BLAKE, simplified and sped up. In software on 64-bit hardware it is usually faster than SHA-256 and SHA-512, and faster than MD5 while being a modern, unbroken function.
The same length as SHA-256, which is a trap for verifying
A BLAKE2b-256 digest is 64 hex characters, exactly like SHA-256 and like SHA3-256. Nothing in the digest says which algorithm produced it. When you verify with POST /hash_verify, name the algorithm in an algorithm field; without it a 64-character hash is read as SHA-256, as it always was.
When you want the interoperability default of the same length, call the SHA-256 hash API endpoint. This service does not offer the 64 byte BLAKE2b-512.
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":"a21cf4b3604cf4b2bc53e6f88f6a4d75ef5ff4ab415f3e99aea6b61c8249c4d0","algorithm":"blake2b"}'{"match":true,"algorithm":"blake2b","computed":"a21cf4b3604cf4b2bc53e6f88f6a4d75ef5ff4ab415f3e99aea6b61c8249c4d0"}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
Never keep passwords as BLAKE2b digests. Speed is a design goal of this algorithm, and speed is precisely the wrong property for password storage. Reach for a deliberately slow key derivation function instead: Argon2id, scrypt or bcrypt, each of which salts per password and exposes a tunable work factor. Since 3 October 2026 this service offers all three on their own routes, for test data: Argon2id, bcrypt and scrypt.
Common uses
Callers reach for the free BLAKE2b hash API endpoint in a handful of recurring situations.
Fast content fingerprints
Fingerprint files and blobs where SHA-256 is slower than you would like and no standard forces the choice. Identical bytes give identical keys.
Checking libsodium output
When your code calls crypto_generichash with a 32 byte output and no key, hash the same input here to confirm the parameters are what you think they are.
Deduplication
Key a cache or object store by digest so duplicate uploads collapse into one stored object, at BLAKE2 speed.
Cross-implementation debugging
Two BLAKE2b implementations that disagree almost always differ in output length or key. A neutral third value shows which parameter is off.
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 BLAKE2b hash API endpoint shares the service-wide ceiling of 5000 requests per IP per day. 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.