JWT Secret Generator
Generate HMAC signing secrets that meet RFC 7518 minimum key size requirements. Choose your algorithm, encoding, and copy the result. 100% client-side.
DID YOU KNOW?
In 2022, Auth0 disclosed that short JWT signing keys allowed attackers to brute-force the secret and forge tokens. RFC 7518 requires HS256 keys to be at least 256 bits (32 bytes), HS384 at least 384 bits, and HS512 at least 512 bits. Using a shorter key is technically valid but cryptographically weak.
JWT signing secrets explained
What is a JWT signing secret?
A JWT signing secret is the key used to create and verify the signature of JSON Web Tokens. For HMAC algorithms (HS256, HS384, HS512), this is a symmetric key — the same secret signs and verifies. The secret must be long enough to match the hash algorithm's output (32 bytes for HS256, 48 for HS384, 64 for HS512). If your secret is too short, an attacker can brute-force it and forge valid tokens.
HMAC (HS) vs RSA (RS) vs ECDSA (ES)
HMAC is symmetric: one shared secret for signing and verification. It's simpler, faster, and ideal for single-service architectures. RSA (RS256) uses asymmetric key pairs — a private key signs, a public key verifies. Better for microservices where multiple services need to verify tokens but only one should sign them. ECDSA (ES256) offers the same benefits as RSA with smaller key sizes. Choose based on your architecture, not perceived security.
Common JWT secret mistakes
Using a short or guessable secret (like 'secret' or your app name) is the #1 mistake. Others: sharing the same secret across environments (dev/staging/prod), not rotating secrets after team member departures, embedding secrets in source code, and using the 'none' algorithm in production. Always generate a full-entropy random key and store it in a vault.
More developer security tools
JWT secret generator FAQ
RFC 7518 specifies minimum key sizes: HS256 requires at least 32 bytes (256 bits), HS384 requires 48 bytes (384 bits), and HS512 requires 64 bytes (512 bits). This generator creates keys that exactly match these requirements. Using shorter keys is technically possible but reduces security.
Use HS256 (HMAC) when one service both signs and verifies tokens — it's simpler and faster. Use RS256 (RSA) when multiple services need to verify tokens but only one should create them, because you can share the public key freely. For most web apps with a single backend, HS256 is the right choice.
No. Use different secrets for development, staging, and production. If your dev secret leaks (e.g., committed to git), it shouldn't compromise production. Generate a unique secret per environment and store each in your secrets vault.
Rotate every 90 days as a baseline, and immediately if you suspect a compromise. Implement a rotation strategy with overlapping validity: accept both old and new secrets during a transition window, then fully deprecate the old one. SecureCodeHQ supports this with TTL and versioned secrets.
Store your JWT signing secrets in SecureCodeHQ instead of .env files. Access them from your app via the SDK (loadEnv or getSecret), and from Claude Code via MCP. Every access is logged, secrets are encrypted with AES-256-GCM, and you can set rotation reminders with TTL.
Generated a JWT secret? Store it properly.
SecureCodeHQ encrypts your JWT secrets and provides access via MCP, SDK, and CLI. Never commit signing keys to git again.