When you start working with JWT, one of the first decisions you face is which signing algorithm to use. The two most common choices are HS256 and RS256, and the decision has implications for security, performance, architecture, and operational complexity.
The wrong choice isn't just a technical inconvenience. It can create security vulnerabilities, make key management harder than it needs to be, or force you into architectural compromises. This guide breaks down the differences clearly so you can make an informed decision.
The Fundamental Difference
The core distinction between HS256 and RS256 is the type of cryptography they use.
HS256 (HMAC with SHA-256) is a symmetric algorithm. The same secret is used both to sign tokens and to verify them. Whoever can verify tokens can also sign them. This means every service that needs to verify tokens must have access to the secret, and every service with the secret can forge tokens.
RS256 (RSA Signature with SHA-256) is an asymmetric algorithm. It uses a pair of keys: a private key that signs tokens and a public key that verifies them. The public key can be freely distributed because it can only verify, not sign. Services that need to verify tokens get the public key, but only the token issuer holds the private key.
This difference is the foundation of all the other distinctions between the two algorithms.
HS256: Simpler, Faster, Symmetric
HS256 is the default algorithm for most JWT libraries, and for good reason. It's simple to implement, fast to compute, and easy to reason about.
**How it works:** You generate a random secret (at least 256 bits). You use that secret to sign tokens. You use the same secret to verify tokens. The secret must be kept confidential because anyone who has it can sign tokens.
Advantages:
Simplicity is the biggest advantage. One secret, one configuration, one thing to manage. There's no key pair generation, no public key distribution, no JWKS endpoint. You generate a secret, store it securely, and you're done.
Performance is another advantage. HMAC computation is significantly faster than RSA signature computation. For high-throughput systems issuing or verifying thousands of tokens per second, the performance difference can matter. HS256 verification is typically 10-100x faster than RS256.
Key management is straightforward. You have one secret to rotate, one secret to store, one secret to distribute to verifying services. For single-server applications or monolithic backends, this simplicity is hard to beat.
Disadvantages:
The main disadvantage is the shared secret problem. Every service that verifies tokens needs the secret, and every service with the secret can forge tokens. In a microservices architecture, this means the secret is distributed widely, increasing the attack surface. If any service is compromised, the attacker can forge tokens for the entire system.
There's also no way to distinguish between signing and verification capabilities. A service that can verify tokens inherently can also sign them. You can't give a service read-only access to token verification without also giving it the ability to forge tokens.
RS256: More Flexible, Asymmetric, Distributed
RS256 uses public-key cryptography, which introduces more complexity but also more flexibility and better security properties for distributed systems.
**How it works:** You generate an RSA key pair (typically 2048 bits or larger). The private key signs tokens. The public key verifies them. The private key stays with the token issuer. The public key is distributed to any service that needs to verify tokens.
Advantages:
Separation of signing and verification is the key advantage. Only the authentication service holds the private key and can sign tokens. Other services hold only the public key and can verify but not forge tokens. If a downstream service is compromised, the attacker can't mint tokens because they don't have the private key.
Public key distribution via JWKS (JSON Web Key Set) endpoints is a powerful feature. Your authentication service publishes its public keys at a well-known URL. Other services fetch the keys automatically, verify them, and cache them. When you rotate keys, you publish new keys to the JWKS endpoint, and verifying services pick them up without any manual configuration.
Non-repudiation is another property of RS256. Because only the private key holder can sign tokens, a valid token is cryptographic proof that it came from the issuer. With HS256, any holder of the shared secret could have signed the token, so you can't prove which service issued it.
Disadvantages:
Complexity is the main disadvantage. You need to generate and manage a key pair, distribute the public key, set up a JWKS endpoint (or share keys manually), and handle key rotation for both keys. This is more operational overhead than HS256's single secret.
Performance is slower. RSA signature verification is computationally expensive compared to HMAC. For systems verifying many tokens per second, this can add up. RSA key generation is also slow, though this only matters during setup and rotation.
Key size is larger. RSA keys are typically 2048 or 3072 bits, compared to HS256's 256-bit secret. The tokens themselves are also larger because RSA signatures are longer than HMAC signatures. This affects bandwidth and storage, though usually not significantly.
When to Choose HS256
HS256 is the right choice for:
**Single-server applications.** If one server signs and verifies all tokens, there's no need for the complexity of asymmetric keys. The secret never leaves the server, and the shared secret problem doesn't apply.
**Monolithic backends.** Even if your backend has multiple internal services, if they all run in the same trust boundary and share the same secret, HS256 is simpler and faster.
**Internal systems.** If your tokens are used only within a closed system where all participants are trusted, the shared secret model is fine. The simplicity outweighs the theoretical advantages of asymmetric keys.
**High-performance requirements.** If you're verifying thousands of tokens per second and every millisecond counts, HS256's speed advantage is significant. The CPU savings can be substantial at scale.
When to Choose RS256
RS256 is the right choice for:
**Microservices architectures.** When multiple independent services need to verify tokens, RS256 lets them do so with public keys that can't be used to forge tokens. A compromised downstream service doesn't compromise the entire authentication system.
**Third-party token verification.** If external services or partners need to verify your tokens, you can share your public key without giving them the ability to forge tokens. This is essential for any system where tokens cross trust boundaries.
**Distributed systems with JWKS.** If you want to enable automatic key distribution and rotation, RS256 with a JWKS endpoint is the standard approach. Verifying services fetch keys automatically, and you can rotate keys without manual updates.
**Compliance requirements.** Some security standards and compliance frameworks require or prefer asymmetric cryptography for authentication. RS256 may be necessary to meet these requirements.
The Algorithm Confusion Risk
Regardless of which algorithm you choose, you must protect against algorithm confusion attacks. As we discussed in our guide to JWT security pitfalls, failing to pin the expected algorithm during verification can allow attackers to trick your system into accepting tokens signed with a different algorithm than expected.
If you use RS256, an attacker might try to use your public key as an HMAC secret and submit HS256 tokens. If your library trusts the token's alg header, it will verify the token using HS256 with the public key, which succeeds. Always specify the expected algorithm in your verification call.
Migration Between Algorithms
If you're currently using HS256 and want to switch to RS256 (or vice versa), you can do so without invalidating existing tokens by implementing a transition period.
During the transition, your verification logic accepts tokens signed with either algorithm. New tokens are signed with the target algorithm. Existing tokens signed with the old algorithm are accepted until they expire naturally. Once all old tokens have expired, you remove support for the old algorithm.
This is the same dual-secret grace period strategy used for JWT secret rotation, extended to handle algorithm changes.
The Bottom Line
There's no universally correct answer to HS256 vs RS256. The right choice depends on your architecture, trust model, and operational requirements.
For simple, single-server applications: HS256 is faster, simpler, and perfectly secure when implemented correctly.
For distributed systems, microservices, or scenarios where untrusted services need to verify tokens: RS256 provides better security properties by separating signing and verification capabilities.
Whatever you choose, use a strong secret or key pair. For HS256, generate a cryptographically secure secret of at least 256 bits using our JWT Secret Generator. For RS256, use at least 2048-bit RSA keys, preferably 3072-bit for future-proofing. And always, always pin the expected algorithm during verification to prevent confusion attacks.
