HS256 and RS256 are the two most common algorithms for signing JSON Web Tokens, and the choice between them comes down to one question: does the same party both create and verify the tokens, or do separate parties do each job? HS256 uses a single shared secret; RS256 uses a private key to sign and a public key to verify. Here is how each works, the security trade-offs, and how to decide.
The short answer
Use HS256 when the same trusted service both issues and verifies the tokens, because a single shared secret is simpler and faster. Use RS256 when tokens are issued by one party and verified by others, such as in single sign-on, microservices, or any setup where verifiers should be able to check a token without being able to forge one. When in doubt in a distributed system, RS256 is the safer default.
How HS256 works
HS256 is a symmetric algorithm. It uses one secret key for both signing and verifying. The issuer creates the signature by running the token’s header and payload through the HMAC-SHA256 function together with the secret. A verifier repeats the exact same computation with the same secret and checks that the signatures match.
The defining characteristic is that signing and verifying use the identical key. This makes HS256 simple and fast, but it has a direct consequence: anyone who can verify a token can also create one, because verification requires the same secret that signing does. That is fine when one trusted service does both jobs, and a problem when it does not.
How RS256 works
RS256 is an asymmetric algorithm. It uses a key pair: a private key to sign and a separate public key to verify. The issuer keeps the private key secret and uses it to sign tokens. Verifiers are given only the public key, which lets them confirm a signature is authentic but does not let them create valid tokens of their own.
This separation is the entire point. You can hand the public key to any number of services, third parties, or clients, and they can all verify tokens, yet none of them can forge one, because forging requires the private key that only the issuer holds. This is what makes RS256 the right fit whenever trust needs to be distributed.
HS256 vs RS256 at a glance
| Aspect | HS256 | RS256 |
|---|---|---|
| Type | Symmetric (HMAC) | Asymmetric (RSA) |
| Keys | One shared secret | Private key + public key |
| Who can sign | Anyone with the secret | Only the private key holder |
| Who can verify | Anyone with the secret | Anyone with the public key |
| Speed | Faster | Slower, larger signatures |
| Best for | Single trusted issuer/verifier | Distributed verification, SSO |
The deciding question
Forget the cryptography for a moment and ask one practical question: who needs to verify these tokens?
- One service issues and verifies everything. A single monolithic backend that signs tokens at login and checks them on every request can safely use HS256. There is one trusted party, one secret, and nothing to distribute.
- Multiple independent services verify tokens issued centrally. An identity provider issues tokens that many separate microservices or third-party apps must verify. Here RS256 is correct, because you can give every verifier the public key without giving any of them the power to mint tokens.
If you used HS256 in that second scenario, you would have to share the signing secret with every verifying service, and any one of them, if compromised, could forge tokens for the whole system. RS256 removes that risk entirely.
none, or switching RS256 to HS256 to abuse the public key as an HMAC secret). Never let the token itself dictate how it is verified.
How to tell which algorithm a token uses
The algorithm is named in the token’s header, in the alg field. You do not need to guess. Decode any JWT and the header reveals it immediately:
{
"alg": "RS256",
"typ": "JWT"
}
You can check this for any token with the JWT decoder, which shows the header, payload, and the algorithm at a glance, entirely in your browser. Remember that decoding only reads the token; verifying its signature still requires the appropriate key on your server.
What about ES256?
You may also encounter ES256, which is asymmetric like RS256 but uses elliptic-curve cryptography instead of RSA. It offers similar security to RS256 with smaller keys and signatures, which is attractive for performance and size. The decision logic is the same as RS256: use it when verification needs to be distributed. The choice between RS256 and ES256 is usually driven by what your libraries and infrastructure support rather than a fundamental difference in the trust model.
Frequently asked questions
Should I use HS256 or RS256 for my JWT?
Use HS256 when one trusted service both issues and verifies tokens, since a single shared secret is simpler and faster. Use RS256 when tokens are issued centrally and verified by separate services, so verifiers can validate without being able to forge tokens.
Is RS256 more secure than HS256?
Neither is inherently more secure; they suit different trust models. RS256 is safer specifically in distributed setups because the signing key is never shared with verifiers. In a single-issuer system, a well-protected HS256 secret is perfectly secure.
Can I switch a token from HS256 to RS256?
You change the algorithm where tokens are signed and verified, not on existing tokens. Update your issuer to sign with the new algorithm and your verifiers to expect it. Always pin the accepted algorithm to prevent algorithm-substitution attacks.
Why is RS256 slower than HS256?
RSA operations are more computationally expensive than HMAC, and RS256 signatures are larger. For most applications the difference is negligible, but at very high token volumes it can matter.
How do I know which algorithm a JWT uses?
Check the alg field in the token header. Decoding the token reveals it instantly; you can use a JWT decoder to read the header without needing any key.
