HS384: HMAC with SHA-384 in a JWT
HS384 is HMAC with SHA-384, the same symmetric construction as HS256 with a longer digest. It is optional in RFC 7518 and uncommon in the wild, which makes interoperability its main practical problem.
At a glance
- Algorithm
- HS384, HMAC using SHA-384
- Registered in
- RFC 7518 section 3.2
- Implementation requirement
- Optional
- Key
- One shared secret, at least 384 bits, which is 48 bytes
- Signature size
- 48 bytes, 64 base64url characters
- Verified in the decoder
- Yes, in your browser, with a shared secret and the same Base64URL secret option as HS256.
In detail
SHA-384 is not a smaller relative of SHA-256. It is SHA-512 run with different initial values and truncated to 384 bits, which means it processes data in 64 bit words and 128 byte blocks. On 64 bit hardware that usually makes it faster per byte than SHA-256, so the longer digest does not automatically cost more time, though for tokens of a few hundred bytes the difference is not something anyone will notice.
Against HS256 the honest gain is small. The digest goes from 32 to 48 bytes and the token grows by 21 base64url characters. HMAC security is bounded by the secret and the underlying hash, and SHA-256 is not the weak point in any current deployment, so choosing HS384 is usually a policy decision, a standard that specifies a 192 bit security level, rather than a response to a real threat.
The cost lands in interoperability. RFC 7518 marks HS384 optional, and only HS256 is required, so a verifier is entitled to reject it. Deployments that switch typically discover one library, gateway or partner integration that does not offer it, and the failure arrives as an unsupported algorithm error rather than an invalid signature, which at least points at the cause.
The decoder verifies HS384 in the browser alongside HS256 and HS512. Paste the secret, use the Base64URL checkbox when the stored secret is encoded, and read the result locally. That matters more for a less common algorithm, since checking whether a token is genuinely valid usually means finding a tool that supports the algorithm at all.
Examples
Header: { "alg": "HS384", "typ": "JWT" }
// third part of the token, 64 base64url characters
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxHS256 produces 43 characters and HS512 produces 86, so the third part alone tells you which was used.
Things that catch people out
- Assuming a 48 byte secret is required because the digest is 48 bytes. RFC 7518 sets that as the minimum key length, and a longer secret is fine while a shorter one is not.
- Choosing HS384 for security while keeping a weak secret. The secret is the limit, not the hash, so a passphrase undoes the upgrade entirely.
- Switching an existing deployment without checking every verifier. HS384 is optional in RFC 7518, so some implementations will simply refuse it.
Try it: JWT Decoder
Paste a token to decode the header and payload, read the claims and expiry, and verify the signature in your browser. Nothing is uploaded.
JWT Decoder
LOCAL · Browser-OnlyDecode and inspect JSON Web Tokens without sending them to a server
Related JWT claims and algorithms
All jwt claims and algorithms →HS256: HMAC with SHA-256 in a JWT
HS256 signs a JWT with a shared secret using HMAC and SHA-256. Key sizing, the algorithm confusion attack, and verifying one in your browser.
HS512: HMAC with SHA-512 in a JWT
HS512 signs a JWT with a shared secret using HMAC and SHA-512. Secret sizing, the token size cost, and how the decoder verifies one in your browser.
alg (Algorithm) Header Parameter in a JWT
The alg header names the algorithm used to sign a JWT. Why the accepted algorithms belong in configuration, and what the decoder does with the value.
RS256: RSASSA-PKCS1-v1_5 with SHA-256 in a JWT
RS256 signs a JWT with an RSA private key and verifies with the public key. Key sizes, the RS256 to HS256 confusion attack, and verifying in your browser.
RS384: RSASSA-PKCS1-v1_5 with SHA-384 in a JWT
RS384 signs a JWT with RSA and SHA-384. What changes against RS256, what does not, and why the token size stays the same for a given key.
RS512: RSASSA-PKCS1-v1_5 with SHA-512 in a JWT
RS512 signs a JWT with RSA and SHA-512. Why the signature length follows the key rather than the hash, and what the decoder needs to verify one.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server
- Hash Generator Free online hash generator - generate MD5, SHA-1, SHA-256 hashes from any input text