What this SHA-384 generator does
This tool computes the SHA-384 cryptographic hash of any text you enter, returning a fixed 384-bit value as 96 hexadecimal characters. SHA-384 is less commonly discussed than SHA-256 or SHA-512, but it has a specific and important use case: TLS cipher suites, code-signing certificates, and subresource integrity (SRI) hashes where a 192-bit security level is needed and where length-extension resistance matters.
How SHA-384 works
SHA-384 belongs to the SHA-2 family defined in NIST FIPS 180-4. Internally it runs the same compression function as SHA-512 — operating on 64-bit words across 80 rounds in 1024-bit message blocks — but seeds the eight working variables with a different set of initial hash values. After processing the padded message, only the first 384 bits (the first six of the eight 64-bit output words) are emitted as the digest.
This tool calls the browser’s native crypto.subtle.digest("SHA-384", data) so results match the standard byte-for-byte.
Why SHA-384 instead of SHA-512?
The choice between SHA-384 and SHA-512 comes down to two factors:
Length-extension resistance. SHA-512 is vulnerable to length-extension attacks — given SHA-512(message) and the length of message, an attacker can compute SHA-512(message || padding || suffix) without knowing message. SHA-384’s truncation means the attacker does not have the full internal state, so this attack does not work. This matters for HMAC-like constructions built naively from SHA-512, though proper HMAC use is not vulnerable regardless.
Output size. SHA-384 produces 96 hex characters versus SHA-512’s 128, which is smaller in storage and transmission while still providing a 192-bit collision-resistance level — more than adequate for any current security requirement.
Where SHA-384 appears in practice
- TLS 1.3 cipher suites —
TLS_AES_256_GCM_SHA384is one of the two mandatory cipher suites, meaning every TLS 1.3 implementation must support SHA-384 for transcript hashing - ECDSA P-384 certificates — NIST recommends pairing the P-384 elliptic curve with SHA-384 for equivalent 192-bit security across the signature and hash components
- Subresource Integrity (SRI) — the
integrityattribute in HTMLlinkandscripttags commonly usessha384-Base64stringto verify CDN-delivered assets; SHA-384 is the recommended choice in the SRI specification - JWT (RS384/ES384/PS384) — JSON Web Token algorithms at the 384-bit level use SHA-384 for their message digest
SHA-384 vs other SHA-2 members
| Algorithm | Bits | Security level | Block size | Speed (relative) |
|---|---|---|---|---|
| SHA-256 | 256 | 128-bit | 512-bit | Faster on 32-bit |
| SHA-384 | 384 | 192-bit | 1024-bit | Faster on 64-bit |
| SHA-512 | 512 | 256-bit | 1024-bit | Fastest on 64-bit |
On 64-bit hardware, SHA-384 and SHA-512 run at nearly the same speed because they share the same compression function — the only difference is how many output words you keep.
Reference values and notes
- Empty string:
38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b abc:cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a43ff5bed8086072ba1e7cc2358baeca134c825a7
Use these to verify that any SHA-384 implementation is computing correctly. As with all SHA-2 variants, never use a bare hash for password storage — use a salted slow KDF such as Argon2 or bcrypt. Everything runs in your browser; nothing is uploaded.