HS256 vs RS256: shared secret or public key for signing JWTs?

How this is calculated

With HS256, the secret is the whole security story. RFC 7518 requires a key at least as long as the hash output, so 256 bits, which is 32 random bytes. A human password like "secret123" is far too weak, because anyone holding one valid token can test guesses offline on a GPU at a huge rate. Every verifier needs a copy of the secret, so a leak from any of them lets an attacker sign tokens for all of them. RS256 splits those roles. Only the issuer holds the private key. APIs, gateways and other teams fetch the public key, usually from a JWKS endpoint, and a leaked public key is harmless. That's why OpenID Connect providers sign ID tokens with RS256 by default and publish their keys. The cost is size and speed. An HS256 signature is 32 bytes, which is 43 Base64url characters, while a 2048-bit RSA signature is 342. Signing with RSA also takes noticeably longer than HMAC, though verifying is still quick. Whichever you choose, the verifier should only accept the algorithm it expects, never whatever the header says.

Verdict

For a single app with its own login, HS256 with a 32-byte random secret is simple and safe. As soon as a second service or a third party verifies your tokens, move to asymmetric keys, either RS256 for the widest library support or ES256 for compact signatures. Pin the expected algorithm in every verifier.