RS256 vs HS256: Which JWT Algorithm Should You Use?
Both produce a signed JWT. The difference is entirely about who can verify the signature, and that has real architectural consequences.
HS256 — one shared secret
HS256 (HMAC-SHA256) uses a single secret to both sign and verify. Whoever holds that secret can do both — issue new valid tokens and verify existing ones. That's fine when one service issues and verifies its own tokens, but it means you cannot safely give that secret to a third party or another microservice just so it can verify tokens: giving it the secret also gives it the power to forge tokens.
RS256 — a key pair
RS256 (RSA signature with SHA-256) uses a private key to sign and a separate public key to verify. The private key stays only with the issuer (e.g. your auth server); the public key can be handed out freely — published at a /.well-known/jwks.json endpoint, embedded in client apps, shared with partner services — because possessing it only lets you verify tokens, not create new valid ones.
Practical rule of thumb
- Single service, issues and verifies its own tokens: HS256 is simpler and faster.
- Multiple services need to verify tokens, but only one should issue them (the typical microservices/API-gateway setup): use RS256 (or ES256) so verification can be distributed without distributing the ability to forge tokens.
- Third-party clients need to verify your tokens (e.g. an SDK, a partner integration): RS256 — you publish the public key, they verify, your signing key never leaves your servers.
What about ES256?
ES256 (ECDSA with P-256) is the same key-pair model as RS256 but with elliptic-curve cryptography — smaller keys and signatures for equivalent security, at the cost of slightly more complex implementation. Functionally, treat it as a modern alternative to RS256 with the same public/private split.
Try it
Cryonel's JWT Decoder verifies HS256/384/512 with a shared secret and RS256/384/512 or ES256/384 with a PEM public key or pasted JWKS JSON, so you can test both models directly.