RS512: RSASSA-PKCS1-v1_5 with SHA-512 in a JWT
RS512 is RSA PKCS#1 v1.5 signing with SHA-512. The 512 in the name refers to the hash, not the key, and the signature is the size of the RSA modulus regardless.
At a glance
- Algorithm
- RS512, RSASSA-PKCS1-v1_5 using SHA-512
- Registered in
- RFC 7518 section 3.3
- Implementation requirement
- Optional
- Key
- RSA key pair, 2048 bits or larger. The name says nothing about the key size.
- Signature size
- Equal to the key size: 256 bytes for 2048 bits, 512 bytes for 4096 bits
- Verified in the decoder
- Yes, in your browser, with a PEM public key. No private key is involved in verification.
In detail
The naming trips people repeatedly. In HS512 the number is the hash size and the key is symmetric; in ES512 it points at curve P-521; in RS512 it is the digest and the key size is a separate decision entirely. A 2048 bit RSA key signing with SHA-512 is a perfectly ordinary RS512 configuration, and nothing about the algorithm name implies a 4096 bit key.
Signature length follows the modulus, so RS512 with a 2048 bit key yields the same 342 base64url characters as RS256 with that key. The digest is hashed down to 64 bytes and wrapped inside the PKCS#1 v1.5 structure before the RSA operation, so the extra hash output is absorbed rather than added. The only way to make the token longer is to use a longer key.
SHA-512 is the same underlying compression function as SHA-384 without the truncation, and on 64 bit hardware it is fast. The cost that matters is the RSA operation itself: signing scales sharply with key size while verification stays cheap, so an issuer minting many tokens per second feels a 4096 bit key long before any resource server does.
For verification the decoder needs the PEM public key and nothing else, and it does the work in your browser. If a token fails here with the correct key, the signature really is wrong, which rules out the two usual suspects at once: an unsupported algorithm in whatever rejected it, and a key that was published for a different signing key entirely.
Examples
// All of these are valid RS512 configurations
RSA 2048 bit key + SHA-512 -> 256 byte signature
RSA 3072 bit key + SHA-512 -> 384 byte signature
RSA 4096 bit key + SHA-512 -> 512 byte signatureThe 512 in RS512 is the digest. Only the key size changes how long the third part of the token gets.
Things that catch people out
- Reading RS512 as requiring a 512 bit key. Such a key would be far below the 2048 bit minimum RFC 7518 sets.
- Choosing RS512 to make tokens smaller or larger. Signature size is set by the key, so the hash choice does not move it.
- Moving to a 4096 bit key for a high volume issuer without measuring. Signing cost rises steeply while verification barely changes.
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 →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.
ES512: ECDSA with P-521 and SHA-512 in a JWT
ES512 signs a JWT with ECDSA on curve P-521 using SHA-512. Why the curve is 521 bits, what that does to signature length, and how to verify it.
PS256: RSASSA-PSS with SHA-256 in a JWT
PS256 signs a JWT using RSA-PSS with SHA-256 and MGF1. How it differs from RS256, why two signatures differ, and verifying with a public key.
PS384: RSASSA-PSS with SHA-384 in a JWT
PS384 signs a JWT using RSA-PSS with SHA-384 and a 48 byte salt. What changes against PS256, and how the decoder verifies one in your browser.
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.
Tools for this
- JWT Decoder Free online JWT decoder - decode and inspect JSON Web Tokens without sending them to a server