JWT Signing Algorithms
6 implementation guides for the JWT signing algorithms you will actually ship. Each page covers how signing and verification work, when to choose the algorithm, key length rules, security pitfalls, and copy-paste code in multiple languages.
Symmetric HMAC algorithms (HS256, HS384, HS512) use one shared secret for both signing and verification — simple for monoliths. Asymmetric algorithms (RS256, ES256, PS256) sign with a private key and verify with a public key or JWKS — better when many services verify tokens without holding the signing key.
HS256 (HMAC-SHA256)
HS256 is the default symmetric JWT signing algorithm in most stacks: one shared secret signs and verifies every token using HMAC-SHA256 as registered in RFC 7518. You implement it when a single auth service or tightly coupled backend both issues and validates tokens, and you can store a high-entropy secret in environment variables or a secrets manager. It is fast, library support is universal, and operational setup is minimal compared to RSA or ECDSA key pairs. The trade-off is that every verifier must possess the signing secret, which expands your blast radius if one service leaks credentials or logs the key by mistake.
RS256 (RSA-SHA256)
RS256 signs JWTs with an RSA private key and verifies them with the corresponding public key, using RSASSA-PKCS1-v1_5 with SHA-256 as defined in RFC 7518. Only your authorization service needs the private key; API gateways, microservices, and partner integrations validate tokens using PEM files or a JWKS document at /.well-known/jwks.json. This asymmetric split is the standard pattern for OAuth2 providers, multi-tenant SaaS platforms, and enterprise APIs where distributing a shared HMAC secret to every consumer is impractical or unacceptable. Implementation requires key generation, secure private key storage, and a plan to publish and rotate public keys without downtime.
ES256 (ECDSA P-256)
ES256 signs JWTs with ECDSA on the P-256 (secp256r1) curve using SHA-256, registered in RFC 7518 as the mainstream elliptic-curve option for JSON Web Tokens. Compared to RS256, ES256 delivers comparable security with dramatically smaller keys and signatures—roughly 64-byte ECDSA signatures versus 256-byte RSA outputs at 2048-bit security levels. Platform teams choose ES256 for mobile backends, IoT gateways, and high-volume APIs where bandwidth and JWKS payload size matter, provided their language libraries and HSM support secp256r1. Implementation mirrors RS256 asymmetrically: one private key signs, many services verify with the public key or JWKS, but PEM encoding and signature malleability handling require extra care.
HS384 (HMAC-SHA384)
HS384 is a symmetric JWT signing algorithm defined in RFC 7518 that combines HMAC with the SHA-384 hash function. The issuer and every verifier share one secret key, so any service holding that secret can both sign and verify tokens. HS384 sits between HS256 and HS512 in hash output size and recommended secret length. It is less common in mainstream web APIs than HS256, yet it appears in enterprises that mandate SHA-384 minimum strength or migrate from legacy security baselines. When implemented with a 384-bit random secret, explicit algorithm allowlists at verification time, and centralized secret storage, HS384 delivers reliable authentication for monoliths and tightly coupled services where distributing a shared secret is acceptable.
HS512 (HMAC-SHA512)
HS512 is the strongest widely supported symmetric JWT algorithm in RFC 7518, combining HMAC with the SHA-512 hash function. Like HS256 and HS384, it uses a single shared secret for both signing and verification, making it straightforward to implement in monoliths and internal APIs. HS512 requires a 512-bit (64-byte) secret to align with the hash block size and produces a 512-bit signature digest. It appears in high-assurance environments, regulated industries, and compliance frameworks that explicitly mandate SHA-512 for message authentication. For most SaaS and consumer web applications, HS256 remains the pragmatic default; HS512 is the choice when policy, defense-in-depth, or organizational standards demand the largest SHA-2 family hash for HMAC-based JWT signing.
PS256 (RSA-PSS SHA-256)
PS256 is an asymmetric JWT signing algorithm that combines RSA with PSS padding and SHA-256, defined in RFC 7518 as part of the RSA-PSS family. Only the authorization server holds the RSA private key; resource servers and third parties verify tokens with the public key distributed via PEM files or a JWKS endpoint. PSS provides tighter security proofs than the PKCS#1 v1.5 padding used by RS256, making PS256 the preferred RSA choice in modern cryptographic designs and some financial API standards. PS256 uses the same minimum 2048-bit RSA key sizes as RS256 — the difference is padding scheme, not key length. Adoption requires confirming library and gateway support across your stack, but for greenfield asymmetric deployments where all verifiers support PSS, PS256 offers the strongest RSA-based JWT signing option available in mainstream JOSE implementations.