Numbers
JWT Secret Key Generator
Used by developers, writers, and creators worldwide.
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.
Loading usage…
Free forever — no account required
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
For HS256, use at least 32 bytes (256 bits); for HS512, at least 64 bytes. Keys shorter than the algorithm's output size are padded internally, which reduces effective entropy. Defaulting to 64 bytes means one key works safely across all three HMAC algorithms without regenerating when you upgrade.
is it safe to generate JWT secrets in the browser
Yes, as long as the tool uses the Web Crypto API's cryptographically secure random number generator rather than Math.random(). This generator does exactly that, and no key is sent to any server or stored anywhere. Copy the key directly into your secrets manager or environment variable and discard the browser tab.
what's the difference between hex and base64url for a JWT secret
Hex encodes each byte as two ASCII characters, making keys verbose but easy to paste into most config files without escaping. Base64URL is roughly 33% shorter and is natively accepted by most JWT libraries without extra decoding. Use alphanumeric if your environment — shell scripts, YAML anchors, or some secrets managers — rejects characters like +, /, and =.