HS512: HMAC with SHA-512 in a JWT
HS512 is HMAC with SHA-512, the largest of the three symmetric options. It produces a 64 byte signature, so it adds the most to token size, and it demands the longest secret of the three.
At a glance
- Algorithm
- HS512, HMAC using SHA-512
- Registered in
- RFC 7518 section 3.2
- Implementation requirement
- Optional
- Key
- One shared secret, at least 512 bits, which is 64 bytes
- Signature size
- 64 bytes, 86 base64url characters
- Verified in the decoder
- Yes, in your browser, with a shared secret and an option to read that secret as Base64URL.
In detail
The 512 bit minimum key length is the practical difference from HS256. Sixty four bytes of random data is not something anyone types, so the secret has to be generated and stored properly, which is a habit worth having anyway. HMAC internally hashes any key longer than the block size, so an over long secret is not an error, but a short one leaves the algorithm no stronger than the entropy behind it.
Size is the visible cost. The signature adds 86 base64url characters to the token against 43 for HS256, and tokens travel on every request. In a cookie with a four kilobyte limit, or a header a proxy caps, an extra 43 characters per token is occasionally the difference between working and not, particularly when the payload already carries roles or scopes.
Where HS512 genuinely fits is a compliance target that names a 256 bit security level, or an internal service to service link where both ends are yours, the secret is machine generated, and nothing else needs to verify. Outside that, the reason to reach past HS256 is usually the wrong one: a longer hash does not compensate for a secret somebody chose by hand.
The decoder verifies HS512 in your browser, same flow as the other two HMAC options: paste the token, paste the secret, tick Base64URL when the stored value is encoded. Nothing is uploaded, so verifying a service to service token with the live secret does not send either of them anywhere.
Examples
# 64 random bytes, base64url encoded for storage
openssl rand -base64 64 | tr '+/' '-_' | tr -d '=\n'
// Header the issuer then writes
{ "alg": "HS512", "typ": "JWT" }Store it encoded and tick the Base64URL box in the decoder, or store the raw text and leave the box clear. Mixing the two fails silently.
Things that catch people out
- Padding a short secret out to 64 characters with repeated text. The length requirement is about entropy, and repetition adds none.
- Overlooking the extra 43 characters per token when the token lives in a cookie or a header with a size limit.
- Expecting universal support. Like HS384, HS512 is optional in RFC 7518, so a partner's verifier may only implement HS256.
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.
HS384: HMAC with SHA-384 in a JWT
HS384 signs a JWT with a shared secret using HMAC and SHA-384. How it differs from HS256, why SHA-384 is a truncated SHA-512, and verification support.
PS512: RSASSA-PSS with SHA-512 in a JWT
PS512 signs a JWT using RSA-PSS with SHA-512 and a 64 byte salt. Why very small keys cannot carry it, and how verification works in the decoder.
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