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.

Verification policy matters more than the label

Do not let the token choose any algorithm the library supports. Configure the accepted algorithm, issuer, audience, and key source for each trust boundary. Algorithm-confusion vulnerabilities occur when a verifier interprets key material under the wrong scheme or accepts none. Keep HS secrets high-entropy and server-only; protect RSA or EC private keys with the same care.

Plan rotation before deployment. Asymmetric issuers can publish overlapping public keys in JWKS and select them with kid. Shared-secret rotation needs a controlled overlap or coordinated cutover across every verifier. In both cases, monitor unknown key IDs and signature failures without logging complete tokens.

Frequently Asked Questions

Related Tools and Guides