JWT Secret Key Generator

Generate cryptographically strong, high-entropy signing secrets for HMAC-SHA256 (HS256), HS384, and HS512 algorithms. Keys are computed in local browser memory with zero network latency or server transmission.

JWT Secret Key Configuration

Cryptographically secure pseudo-random bytes generated via Web Crypto CSPRNG

1. Select Key Size (Bits & Bytes)RFC 7518 recommends ≥ 256 bits for HS256

2. Select Output Encoding

3. Generated Cryptographic Secret

No secret generated yet

Click below to generate a cryptographically secure key in your browser.

Integration Code Snippets

Live preview with your generated key

# .env configuration (Never commit this to version control)
JWT_SECRET="YOUR_GENERATED_SECRET_HERE"
JWT_EXPIRES_IN="15m"
JWT_ALGORITHM="HS256"

HMAC Algorithm Minimum Key Size Requirements (RFC 7518)

When using HMAC algorithms (HS256, HS384, HS512), the cryptographic integrity of your tokens is directly bounded by the entropy of your secret key. RFC 7518 (JSON Web Algorithms) dictates that keys must be equal to or greater than the hash function digest size:

Algorithm	Minimum Key Size	Raw Bytes	Hex String Length
HS256	256 bits	32 bytes	64 characters
HS384	384 bits	48 bytes	96 characters
HS512	512 bits	64 bytes	128 characters

*Warning:* Using a 128-bit key for HS256 violates RFC 7518 and makes offline dictionary and brute-force attacks computationally feasible.

Safe Secret Storage & Environment Variable Best Practices

A cryptographically secure key is only as safe as its storage location. Follow these four production rules:

Never commit secrets to Git: Ensure .env and local configuration files are explicitly ignored in your .gitignore.
Never embed secrets in frontend JavaScript: Client-side code (React, Vue, mobile apps) can be inspected by anyone using browser developer tools. Secrets must reside exclusively on the server.
Validate secret presence at startup: Configure your application to abort immediately if JWT_SECRET is missing or shorter than 32 characters.
Establish a key rotation plan: Use the kid (Key ID) header claim to support multiple active keys during scheduled rotations.

Frequently Asked Questions

How does this tool generate random secrets?

This tool calls window.crypto.getRandomValues() directly in your browser. The operating system kernel (via /dev/urandom on Linux/macOS or BCryptGenRandom on Windows) gathers hardware entropy from physical interrupts, thermal variations, and timing jitter to supply true cryptographic randomness.

Why does 256 bits of Hex result in a 64-character string?

256 bits equals 32 bytes (256 / 8 = 32). In hexadecimal encoding, each byte is represented by exactly 2 characters (00 to ff). Therefore, 32 bytes produces 64 hex characters. The underlying cryptographic entropy is 256 bits.

Can an attacker brute-force a 256-bit secret?

A 256-bit secret drawn from true randomness has 2^256 possible combinations (approximately 1.15 x 10^77). Even with supercomputers testing billions of keys per second, exhaustive brute-force search would require longer than the age of the universe.

How should I store this secret in my production environment?

Store the secret as an environment variable (JWT_SECRET) in a .env file that is excluded from Git. In containerized production (Docker, Kubernetes), inject the secret via Kubernetes Secrets, AWS Secrets Manager, or HashiCorp Vault with strict 600 file permissions.