Call the free SHA3-512 hash API endpoint
curl -X POST https://aisenseapi.com/services/v1/sha3_512_hash \
-H "Content-Type: application/json" \
-d '{"data":"Hello world"}'{"sha3_512_hash":"e2e1c9e522efb2495a178434c8bb8f11000ca23f1fd679058b7d7e141f0cf3433f94fc427ec0b9bebb12f327a3240021053db6091196576d5e6d9bd8fac71c0c"}Count the characters in that value and you get 128. That is 64 bytes, or 512 bits. The digest is a constant: any correct SHA3-512 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_512_hash \
-H "Content-Type: text/plain" \
--data-binary "Hello world"{"sha3_512_hash":"e2e1c9e522efb2495a178434c8bb8f11000ca23f1fd679058b7d7e141f0cf3433f94fc427ec0b9bebb12f327a3240021053db6091196576d5e6d9bd8fac71c0c"}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_512_hash | string | Exactly 128 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 a different design from SHA-2, not a longer version of it. SHA-2 compresses the input block by block; 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.
SHA3-512 gives the same 512-bit output as SHA-512. For a fingerprint the two are interchangeable in strength, and the choice is about where each is expected. SHA-512 is the one most tooling knows. SHA3-512 shows up where a standard names it, and in systems that want a second digest from an unrelated family.
Speed differs from SHA-512 in an unexpected way. SHA3-512 has the smallest sponge rate of the family, 576 bits per permutation, so it is the slowest SHA-3 variant, and in software it is usually slower than SHA-512 on 64-bit hardware. Measure on your own machine if throughput matters.
The same length as SHA-512, which is a trap for verifying
A SHA3-512 digest is 128 hex characters, exactly like SHA-512 and like Whirlpool. 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 128-character hash is read as SHA-512, as it always was.
Truncating this output does not give you SHA3-256. The two are separate functions with different sponge rates, and a cut-down SHA3-512 never matches a real SHA3-256 digest. For the shorter one, call the SHA3-256 hash API endpoint.
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 128-character digest is also what SHA-512 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":"e2e1c9e522efb2495a178434c8bb8f11000ca23f1fd679058b7d7e141f0cf3433f94fc427ec0b9bebb12f327a3240021053db6091196576d5e6d9bd8fac71c0c","algorithm":"sha3_512"}'{"match":true,"algorithm":"sha3_512","computed":"e2e1c9e522efb2495a178434c8bb8f11000ca23f1fd679058b7d7e141f0cf3433f94fc427ec0b9bebb12f327a3240021053db6091196576d5e6d9bd8fac71c0c"}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-512 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-512 hash API endpoint in a handful of recurring situations.
Standard-mandated digests
Some specifications and signature profiles name SHA3-512 explicitly. When that is the requirement, this endpoint produces the exact value a reviewer will check against.
Archival manifests
Record a 512-bit digest from an independent family beside every file in a long-lived archive. A re-hash years later tells you which objects survived intact.
Algorithm independence
Store a SHA-512 and a SHA3-512 digest side by side, so a future break in one construction does not void the other.
Cross-implementation debugging
When two libraries disagree about SHA-3, hash the same input here. A neutral third implementation turns an argument about code into a question about padding or encoding.
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-512 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.