Edit: JWT HS256 vs RS256: Which Should You Ch…

Posts›JWT HS256 vs RS256: Which Should You Ch…

PublishedView Live →

Title

Slug

Preview: https://jwtsecretgenerator.com/blog/jwt-hs256-vs-rs256-guide

⚠ Changing the slug will break existing links to this post.

Description / Excerpt

159 / 180 characters

Content (Markdown)

# JWT HS256 vs RS256: Which Should You Choose?

> **Quick comparison:** See our canonical [HS256 vs RS256 comparison](/compare/hs256-vs-rs256) for a side-by-side breakdown with pros, cons, and verdict.

Choosing between HS256 and RS256 is one of the first architectural decisions you make when implementing JWT authentication. Get it wrong, and you'll face painful refactoring later.

## HS256: Symmetric Signing

HS256 (HMAC with SHA-256) uses a single shared secret for both signing and verification. Every service that needs to verify tokens must know the secret.

**When to use HS256:**
- Single service or monolith architecture
- All token issuance and verification happens within one system
- You want simplicity and maximum performance
- You can securely share the secret with all verification points

```javascript
const jwt = require('jsonwebtoken');
const secret = process.env.JWT_SECRET;

// Signing (auth server)
const token = jwt.sign({ userId: 123 }, secret, { algorithm: 'HS256' });

// Verification (any service with the secret)
const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });
```

## RS256: Asymmetric Signing

RS256 (RSA Signature with SHA-256) uses a private key to sign tokens and a public key to verify them. Only the auth server holds the private key — any service can verify with the public key.

**When to use RS256:**
- Microservices architecture where multiple services verify tokens
- Third-party services need to verify your tokens
- You want to publish a JWKS (JSON Web Key Set) endpoint
- Compromising a verifier should not compromise the signer

```javascript
const jwt = require('jsonwebtoken');

// Signing (auth server only — private key)
const token = jwt.sign({ userId: 123 }, privateKey, { algorithm: 'RS256' });

// Verification (any service — public key only)
const payload = jwt.verify(token, publicKey, { algorithms: ['RS256'] });
```

## Performance Comparison

| Metric | HS256 | RS256 |
|--------|-------|-------|
| Sign speed | Very fast | Slower (RSA math) |
| Verify speed | Very fast | Moderate |
| Key distribution | Requires secure channel | Public key is safe to share |
| Key rotation | All services update | Only auth server |
| JWKS support | No | Yes |

## Key Rotation

With HS256, rotating means distributing the new secret to every service that verifies tokens — a coordination problem at scale.

With RS256, the auth server generates a new key pair, publishes the new public key to its JWKS endpoint, and services automatically pick it up. Only the auth server touches private key material.

## Recommendation

For new projects: **if you have or anticipate microservices, use RS256**. The operational overhead is justified by the security isolation and simplified key distribution.

For simple monoliths: **HS256 with a strong secret** is perfectly secure and much simpler to operate.

Need to generate a strong HS256 secret? Use the [JWT Secret Generator](/tools/jwt-secret-generator). For RS256, generate a 2048-bit or 4096-bit RSA key pair using OpenSSL or your cloud provider's KMS.

481 words · ~3 min readMarkdown guide →

Tags (3/8)

jwtalgorithmssecurity

Author Name

Status

Cover Image URL (optional)

Danger Zone

Deleting this post sets its status to "deleted". It can be recovered via the API.