ToolkitBook
Generate secure secret keys for JWT signing right in your browser. Pick a key length to match your algorithm—256 bits for HS256, 384 for HS384, 512 for HS512. Output in hex, Base64, or Base64URL, or switch to a special-character key with a custom character set. All randomness comes from your browser's built-in crypto API. Nothing is sent to any server.
HMAC with SHA-256. The most common symmetric algorithm for JWT signing.
Recommended: 256-bit keyHMAC with SHA-384. A stronger hash for tighter security requirements.
Recommended: 384-bit keyHMAC with SHA-512. The strongest option for highly sensitive applications.
Recommended: 512-bit keyA JWT (JSON Web Token) secret key is a cryptographic string used to sign and verify tokens in authentication systems. When you create a JWT, the secret key is combined with the header and payload to produce a unique signature that proves the token hasn't been tampered with.
If anyone modifies the token data, the signature check fails and the token is rejected—preventing unauthorized access to your application.
Alphanumeric generates keys using hexadecimal or Base64-encoded bytes—what most JWT libraries expect. Special Characters draws from a wider set including symbols like !@#$%, packing more entropy into each character. The resulting keys are shorter but equally strong, though some JWT libraries may not accept special characters.
256 bits is the sweet spot for most production applications—it's the industry standard and works well with HS256. Step up to 384 or 512 bits for high-security environments like financial or healthcare systems. The rule of thumb: match the key length to your algorithm. HS256 needs at least 256 bits, HS384 needs 384, and HS512 needs 512.
The Encryption Strength slider sets the security level in bits, not the number of characters. A larger character set carries more entropy per character, so fewer characters are needed for the same strength. At 256 bits, a hex key (16 characters to pick from) needs 64 characters, a Base64 key (64 options) needs about 44, and a full alphanumeric-plus-symbols key (~94 options) needs just 39. All three are equally hard to crack—an attacker faces the same 2 to the 256 brute-force effort no matter which format you pick.
Hexadecimal is the default and works with most JWT libraries. It produces a string like "a1b2c3d4e5f6..." using only 0-9 and a-f. Base64 is more compact—roughly 33% shorter—though some libraries expect it decoded first. Base64URL replaces + and / with - and _, making it safe to use in URLs without extra encoding.
This tool uses crypto.getRandomValues(), the same API browsers use for TLS session keys. It draws entropy from your operating system's cryptographic random number generator (/dev/urandom on Unix, CryptGenRandom on Windows). This is not Math.random()—that one is predictable and should never be used for secrets.
The randomness is cryptographically sound. All generation happens locally in your browser—no data is sent to any server. That said, you still need to store and handle the keys securely (environment variables, key management services, etc.). Never commit secret keys to version control.
Rotate JWT secret keys every 90-180 days, and immediately if you suspect a key has been compromised. When rotating, keep a grace period where both old and new keys are accepted so existing sessions aren't disrupted.
Prefer the command line? Here are three ways to produce equivalent keys locally:
OpenSSL (Linux / macOS):
openssl rand -hex 32 — 64-character hex string (256 bits).
openssl rand -base64 32 — Base64-encoded key at the same strength.
Python:
python3 -c "import secrets; print(secrets.token_hex(32))"
The secrets module wraps your OS's secure random source.
Node.js:
node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"