Free JWT Secret Generator — HS256/384/512

What Is a JWT Secret Generator?

// The secret you generate here goes straight into your signing code.
// Node.js with jsonwebtoken — the JWT_SECRET env var holds the key.
import jwt from 'jsonwebtoken';

const secret = process.env.JWT_SECRET; // e.g. base64url value from this tool

// Sign a token with HS256 (HMAC-SHA-256).
const token = jwt.sign({ sub: 'user-42', role: 'member' }, secret, {
  algorithm: 'HS256',
  expiresIn: '15m'
});

// Verify it — pin the algorithm to a whitelist; never trust the token's alg.
const payload = jwt.verify(token, secret, { algorithms: ['HS256'] });

// ---------------------------------------------------------------
// Python with PyJWT — same secret, same algorithm pinning.
// import jwt
// token = jwt.encode({"sub": "user-42"}, key, algorithm="HS256")
// payload = jwt.decode(token, key, algorithms=["HS256"])  # whitelist!

// ---------------------------------------------------------------
// Equivalent-strength CLI generation (32 bytes for HS256):
//   openssl rand -base64 32
//   node -e "console.log(require('crypto').randomBytes(32).toString('base64url'))"
//   python -c "import secrets; print(secrets.token_urlsafe(32))"

Key Features

Worked Examples

Algorithm: HS256 · Format: base64url

3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Algorithm: HS512 · Format: base64url

k2Lp9XqA0mNbVcZ7rT4wYsHfGjUe8RoIdPlNkBvM3xQ1aWtCyZuS6FhEgJ (86 chars)

Click "Copy for .env"

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0

Show the CLI command

openssl rand -base64 32

Toggle the eye icon

•••••••••••••••••••••••••••••••••••••••••••  ↔  3sJ9aFq2kP7m…

How to Use the JWT Secret Generator

1. 1

   Choose the signing algorithm

   Select HS256, HS384, or HS512. The generator instantly applies the RFC 7518 §3.2 minimum key length for that HMAC variant — 32, 48, or 64 bytes — so you never have to look the number up or risk an undersized key.

2. 2

   Pick the output format

   base64url is the default — JWT's native URL-safe, no-padding encoding. Switch to standard base64 if a loader expects it, or hex when a system only accepts 0–f characters. All three encode the same random bytes with identical entropy.

3. 3

   Reveal and copy the secret

   The secret is masked by default to keep it off-screen during a demo or screen share. Click the eye icon to reveal it, then Copy to grab the raw value or Copy for .env to copy a JWT_SECRET=… line ready for a .env file or CI variable.

4. 4

   Regenerate as needed

   Click Regenerate for a fresh, independent secret drawn from crypto.getRandomValues. Generate one per environment — never reuse the same signing key across development, staging, and production.

5. 5

   Use the CLI equivalent or move on to signing

   The CLI panel shows the matching openssl, Node, and Python one-liners for scripted provisioning. With your secret in hand, sign a token with the JWT Encoder and confirm the signature with the JWT Decoder.

Common JWT Secret Mistakes

JWT_SECRET=mySuperSecret123  →  low entropy, brute-forceable

JWT_SECRET=3sJ9aFq2kP7mWcZ1xL0nVtRbYdGhU8eAoI4QpNlKj0  →  32 random bytes

16-byte key with HS256  →  below the 32-byte minimum

32-byte key with HS256  →  meets RFC 7518 §3.2

Math.random()-based key  →  predictable, unsafe

crypto.getRandomValues key  →  full entropy

Service A: raw string · Service B: base64-decoded  →  signatures never match

Both services use the identical stored string  →  signatures verify

Same JWT_SECRET in dev, staging, prod  →  one leak breaks all

A unique secret per environment  →  blast radius contained

jwt.verify(token, secret)  →  accepts the token's alg

jwt.verify(token, secret, { algorithms: ['HS256'] })  →  pinned

Who Uses This Tool

Provision a JWT_SECRET for a New Service

Spinning up an API that issues HMAC-signed tokens? Pick the algorithm your library uses, copy the secret as a JWT_SECRET=… line, and drop it into the service's environment. Generate a distinct key for development, staging, and production — never share one secret across environments.

Rotate a Compromised or Aging Secret

When a key is suspected leaked or simply due for rotation, generate a fresh secret here, assign it a new kid, and roll it out with an overlap window so live tokens keep verifying until they expire. In a confirmed compromise, rotate immediately and drop the old key from the accepted set.

Replace a Weak or Hand-Typed Key

Inherited a codebase whose JWT_SECRET is a short phrase or a copied example value? That key is brute-forceable offline. Generate a full-entropy 32-byte replacement, swap it in behind a rotation window, and close the token-forgery hole before it is exploited.

Script Key Generation in a Pipeline

Need the key created in CI or a Dockerfile rather than by hand? Use the CLI panel's openssl, Node, or Python one-liner to mint an equal-strength secret inside your provisioning script, and use this page to understand the byte lengths and encodings each command produces.

Teach JWT Signing Safely

Walk a team through how HS256 works without ever exposing a real production key — generate a throwaway secret on screen (masked until you reveal it), sign a sample token with the JWT Encoder, and verify it with the JWT Decoder so the whole sign-and-verify loop is visible.

Compare HS256, HS384, and HS512 Key Sizes

Deciding which HMAC variant to standardize on? Flip between the algorithms to see how the required key length and encoded string grow — 43, 64, and 86 base64url characters — and pick the strength-versus-token-size trade-off that fits your system before you commit it to config.

Generate Keys for Local Development

Need a quick, valid secret to get a local auth flow running? Generate one in a click, copy it for .env, and you are unblocked — with a real CSPRNG key rather than a placeholder you will forget to replace before deploy.

How the Generator Works

crypto.getRandomValues (CSPRNG)

Secrets are generated by filling a Uint8Array with crypto.getRandomValues, the Web Crypto cryptographically secure pseudo-random number generator. It is the same entropy source that backs Web Crypto key generation. Math.random is never used anywhere — it is statistically predictable and unfit for any cryptographic key.

RFC 7518 §3.2 Key Sizing

The byte count per algorithm follows the JSON Web Algorithms requirement that an HMAC key be at least the size of the hash output: 32 bytes for HS256 (SHA-256), 48 for HS384 (SHA-384), 64 for HS512 (SHA-512). Selecting the algorithm sets the minimum; the generator will not emit a key below the spec floor.

RFC 4648 Encodings (base64url / base64 / hex)

The raw bytes are encoded with the RFC 4648 alphabets. base64url uses the URL-safe alphabet without padding (32 bytes → 43 chars), standard base64 uses +, /, and = padding (→ 44 chars), and hex writes two characters per byte (→ 64 chars). Switching formats re-encodes the same bytes — the underlying entropy is unchanged.

Why base64url Is the Default

JWT components are themselves base64url-encoded, and the URL-safe, no-padding alphabet means a secret in base64url never needs escaping in a header, a URL, or a config file. Standard base64's + and / and trailing = can break in those contexts, so base64url is the conservative default for a JWT_SECRET.

Copy-for-.env Formatting

Copy for .env emits JWT_SECRET= on a single line with no surrounding quotes — the shape dotenv-style loaders parse without modification. The raw secret never includes characters that would require quoting in a .env file, so the line is safe to paste as-is.

Equivalent-Strength CLI Commands, Not Byte-Identical

The CLI panel's openssl rand -base64 N, Node randomBytes(N).toString('base64url'), and Python secrets.token_urlsafe(N) commands all draw N secure random bytes for the chosen algorithm. They produce equal-strength keys, not the same string — openssl emits padded standard base64, so the alphabet and trailing characters differ from this tool's base64url default.

JWT Secret Best Practices

Match the Key Length to the Algorithm

Use at least 32 bytes for HS256, 48 for HS384, and 64 for HS512, as RFC 7518 §3.2 requires. This generator does it for you, but if you size a key by hand, never go below the hash output length — an undersized HMAC key both weakens the signature and may be rejected by strict libraries.

Always Generate with a CSPRNG, Never a Password

A JWT secret is a machine credential nobody needs to memorize, so spend the full entropy: use a cryptographically secure random key, not a passphrase, a dictionary word, or a hand-typed string. Human-chosen secrets are the easiest target for the offline brute-force attacks that JWT cracking tools automate.

Use a Unique Secret per Environment

Development, staging, and production should each have their own JWT_SECRET. Sharing one key means a leak in a low-stakes environment forges tokens everywhere, and it makes rotation all-or-nothing. Generate a separate secret here for each environment and store each in its own secrets manager scope.

Pin the Algorithm When You Verify

On the verifying side, always pass an explicit algorithm whitelist — algorithms: ['HS256'] in jsonwebtoken, algorithms=["HS256"] in PyJWT — and never trust the alg field inside the token. Accepting the token's self-declared algorithm enables the classic alg-confusion and alg:none forgery attacks, regardless of how strong your secret is.

Rotate with a kid Header and Overlapping Keys

Tag signed tokens with a key identifier (kid) and publish active keys via a JWKS endpoint so you can rotate without downtime: sign new tokens with the new key while still accepting the old one until its tokens expire. On a suspected compromise, skip the overlap and revoke the old key immediately.

Frequently Asked Questions