Call the free SHA3-256 hash API endpoint
curl -X POST https://aisenseapi.com/services/v1/sha3_256_hash \
-H "Content-Type: application/json" \
-d '{"data":"Hello world"}'{"sha3_256_hash":"369183d3786773cef4e56c7b849e7ef5f742867510b676d6b38f8e38a222d8a2"}Count the characters in that value and you get 64. That is 32 bytes, or 256 bits. The digest is a constant: any correct SHA3-256 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/sha3_256_hash \
-H "Content-Type: text/plain" \
--data-binary "Hello world"{"sha3_256_hash":"369183d3786773cef4e56c7b849e7ef5f742867510b676d6b38f8e38a222d8a2"}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 |
|---|---|---|
| sha3_256_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.
What SHA-3 changes, and what it does not
SHA-3 is not a faster or longer SHA-2. It is a different design. SHA-2 is a Merkle-Damgard construction with a compression function; SHA-3 is a sponge that absorbs the input into a 1600-bit state and squeezes the digest out. NIST standardised it in 2015 after an open competition, so that a weakness found in SHA-2 would not take every standard hash down with it.
The output length is the same 256 bits as SHA-256, and for a content fingerprint the two are interchangeable in strength. What differs is where each is expected. Package registries, release checksums and most tooling expect SHA-256. SHA3-256 shows up where a standard or a procurement rule names it, in some blockchain and signature profiles, and in systems that chose it to be independent of the SHA-2 family.
One trap: SHA3-256 and Keccak-256 are not the same function. Ethereum uses the pre-standard Keccak-256 with different padding, and its digests will never match this endpoint. When a document says Keccak, check which one it means.
The same length as SHA-256, which is a trap for verifying
A SHA3-256 digest is 64 hex characters, exactly like SHA-256 and like BLAKE2b-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, and a SHA3-256 digest will come back as a mismatch against the wrong algorithm.
When you want the SHA-2 digest of the same length, call the SHA-256 hash API endpoint. For a 512-bit SHA-3 digest, the SHA3-512 hash API endpoint returns 128 characters.
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":"369183d3786773cef4e56c7b849e7ef5f742867510b676d6b38f8e38a222d8a2","algorithm":"sha3_256"}'{"match":true,"algorithm":"sha3_256","computed":"369183d3786773cef4e56c7b849e7ef5f742867510b676d6b38f8e38a222d8a2"}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 SHA3-256 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 SHA3-256 hash API endpoint in a handful of recurring situations.
Standard-mandated digests
Some specifications and signature profiles name SHA-3 explicitly. When that is the requirement, this endpoint produces the exact value a reviewer will check against.
Algorithm independence
A system that already stores SHA-256 digests can add SHA3-256 as a second, independently constructed fingerprint, so a future break in one family does not void the other.
Cross-implementation debugging
When your library and someone else's disagree about SHA-3, Keccak padding is the usual culprit. Hash the same input here to find out which side has the standard function.
Content addressing
Key a cache or object store by digest so identical bytes always land on the same key. Duplicate uploads then collapse into one stored object.
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 SHA3-256 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.