Numbers
JWT Secret Key Generator
A JWT secret key generator saves you from one of the most common authentication mistakes: weak or reused signing secrets. HMAC-based JWT algorithms like HS256, HS384, and HS512 are only as secure as the entropy behind their key. This tool produces cryptographically strong keys using secure random generation in your browser — nothing is transmitted or logged. Choose your key length in bytes (64 bytes covers HS512 and everything below it), pick hex, Base64URL, or alphanumeric output, and generate up to a batch at once. Base64URL is compact and library-friendly; hex pastes cleanly into config files; alphanumeric avoids special-character issues in strict YAML parsers or shell environments.
How to use
- Choose your options above
- Click Generate
- Copy your result
Detailed instructions
- Set the count field to how many independent keys you need — one per environment is a sensible starting point.
- Set the length to 32 bytes for HS256 or 64 bytes for HS512 (64 is the safe default for any algorithm).
- Choose a format: Base64URL for most JWT libraries, hex for readability, or alphanumeric for restricted environments.
- Click Generate and copy each key directly into your secrets manager, .env file, or CI/CD secret variable.
- Never regenerate unless rotating — treat each key as a one-time credential and store it immediately after copying.
Use Cases
- •Bootstrapping JWT_SECRET in a new Express or Fastify API before first deploy
- •Rotating a compromised signing key in production and redeploying to invalidate forged tokens
- •Generating separate 64-byte secrets for access tokens and refresh tokens in a Next.js app
- •Populating JWT secrets in a Docker Compose secrets block or a Kubernetes Secret manifest
- •Replacing insecure placeholder secrets left behind by create-app boilerplate templates
Tips
- →Generate one key per application environment (dev/staging/prod) in a single run by setting count to 3.
- →Base64URL keys are roughly 25% shorter than hex for the same entropy — useful when environment variable length limits exist.
- →If your JWT library accepts the raw string, paste Base64URL directly; avoid re-encoding it or you will double-encode and break verification.
- →For microservice architectures, give each service its own signing secret so a breach in one service cannot forge tokens consumed by another.
- →After rotating a compromised secret, search your codebase and CI logs for the old key string before considering the incident closed.
- →Alphanumeric format avoids quoting issues in shell scripts and YAML — use it when you cannot control how the value is interpolated.
FAQ
How long should a JWT secret key be for HS256 vs HS512?
The secret should be at least as long as the hash output: 256 bits (32 bytes) for HS256 and 512 bits (64 bytes) for HS512, which is the widely accepted minimum. Longer is fine. A short secret is the most common way HMAC-signed JWTs get broken, so default to 64 bytes for HS512 and never go below the hash size.
Is it safe to generate JWT secrets in the browser?
Yes — the keys are generated with the Web Crypto API (crypto.getRandomValues), which is cryptographically secure, and run locally so nothing is transmitted. That makes them suitable for real signing secrets at the lengths above. Store the secret in your server environment (never in client code or a repo) and rotate it if it is ever exposed.
What is the difference between hex and base64url for a JWT secret?
Both encode the same random bytes; the difference is representation. Hex uses 0–9 and a–f (two characters per byte). Base64url packs the bytes more compactly using a URL-safe alphabet, so the key is shorter for the same entropy. Pick the format your framework or config expects — many accept either.
Where do I store the generated JWT secret?
In a server-side secret store or environment variable (a .env that is gitignored, or a managed secrets service), never in client-side code, a public repo, or a JWT itself. The secret must stay on the signing/verifying server only. If it leaks, anyone can forge valid tokens, so treat it like a password and rotate on exposure.
Should every environment use a different JWT secret?
Yes — use a distinct secret per environment (development, staging, production) so a leak in one does not compromise the others, and so tokens are not valid across environments. Generate a separate key for each and store each in that environment's secret store. Reusing one secret everywhere widens the blast radius of any exposure.
You might also like
Popular tools from other categories that share themes with this one.
Try these next
More free tools from other corners of the catalog, picked by shared themes.