HS256 vs RS256: which JWT signing algorithm should you use?
Both algorithms produce a valid, tamper-evident JSON Web Token. The difference is not strength — it is who is allowed to create tokens. HS256 shares one secret between signer and verifier; RS256 splits them into a private signing key and a public verification key.
The short answer
- One service issues and verifies? Use HS256. It is simpler, faster, and produces smaller tokens.
- Several services or third parties verify? Use RS256, so verifiers hold only a public key and cannot forge tokens.
Side-by-side comparison
| Property | HS256 | RS256 |
|---|---|---|
| Key model | Symmetric — one shared secret | Asymmetric — private key signs, public key verifies |
| Underlying primitive | HMAC with SHA-256 | RSASSA-PKCS1-v1_5 with SHA-256 |
| Minimum key size | 256 bits (32 random bytes) | 2048-bit RSA key pair |
| Speed | Very fast sign and verify | Slower sign, moderately fast verify |
| Token size impact | 256-bit signature (~43 chars) | 2048-bit signature (~342 chars) |
| Who can issue tokens | Anyone holding the secret | Only the holder of the private key |
| Key distribution | Must share the secret securely | Publish the public key or a JWKS URL |
| Best fit | Monolith, single service, internal APIs | Microservices, SSO/OIDC, third-party verifiers |
How HS256 works
HS256 computes an HMAC over the encoded header and payload using a shared secret:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )
Anyone who can verify can also sign, because verification recomputes the same HMAC. That is fine inside a single trust boundary and terrible across many. The secret must come from a CSPRNG and be at least 256 bits — a passphrase is not acceptable. Generate one with the JWT secret generator and check it with the strength validator.
How RS256 works
RS256 signs the same input with an RSA private key and verifies with the matching public key. Verifiers typically fetch that public key from a JWKS endpoint, which also makes key rotation straightforward: publish the new key with a fresh kid, sign new tokens with it, and retire the old one once outstanding tokens expire.
This is the model used by OpenID Connect providers, Auth0, Cognito, and most SSO systems — the identity provider is the only party that can mint tokens. You can create a key pair with the JWK generator.
Performance and token size
HMAC-SHA256 is a single hash pass; RSA signing is modular exponentiation with a private exponent. On typical hardware HS256 signs in microseconds while RS256 signing costs roughly an order of magnitude more, though RSA verification (small public exponent) is comparatively cheap. RS256 also inflates every token by about 300 characters of signature, which matters when tokens ride in headers or cookies on every request.
If signing throughput and token size both matter but you still need asymmetric keys, ES256 (ECDSA on P-256) is a good middle ground: 64-byte signatures and fast operations.
The algorithm-confusion trap
The most common JWT vulnerability involving these two algorithms is accepting the alg value from the token header. If a server expects RS256 but trusts the header, an attacker can send an HS256 token signed with the public RSA key — which is not secret — and the naive verifier will accept it. Always pin the algorithm:
// Node.js — jsonwebtoken
jwt.verify(token, publicKey, { algorithms: ["RS256"] });
# Python — PyJWT
jwt.decode(token, public_key, algorithms=["RS256"])Reject alg: none at the library level too, and validate iss, aud, and exp on every request.
Migrating from HS256 to RS256
- Generate an RSA key pair (2048 bits or larger) and give it a
kid. - Publish the public key at a JWKS endpoint your services can fetch and cache.
- Update verifiers to accept both HS256 and RS256 temporarily, each pinned to its own key — never a single call that accepts both algorithms with one key.
- Switch the issuer to sign new tokens with RS256.
- After the longest token lifetime has passed, drop HS256 support and destroy the old secret.
Frequently asked questions
Is RS256 more secure than HS256?
Not inherently. Both are considered secure when used correctly. RS256 reduces operational risk because verifiers only hold a public key, so a compromised verifier cannot mint tokens. HS256 with a 256-bit random secret is cryptographically strong, but every verifier holds the signing key.
Which is faster, HS256 or RS256?
HS256 is much faster. HMAC-SHA256 is a symmetric hash operation, while RS256 performs RSA signing and verification. In practice HS256 signs and verifies roughly an order of magnitude faster than RS256 with a 2048-bit key.
When should I switch from HS256 to RS256?
Switch when more than one independent service needs to verify tokens, when a third party must verify without being able to issue, or when you publish a JWKS endpoint for federated identity such as OIDC.
What key size does each algorithm need?
HS256 needs a secret of at least 256 bits (32 random bytes). RS256 needs an RSA key pair of at least 2048 bits; 3072 or 4096 bits gives a longer security margin.
Can an attacker swap RS256 for HS256?
Yes — that is the classic algorithm-confusion attack. If a server accepts the token header's alg value, an attacker can sign a token with HS256 using the public RSA key as the HMAC secret. Always pin the expected algorithm in your verification call.