JWT Secret Generator for HS256, HS384 and HS512

How to use the jwt secret generator

1. Select the HMAC algorithm your application uses: HS256, HS384 or HS512.
2. Click Generate to create a new cryptographically random secret.
3. Copy the key in your preferred encoding: hex, standard base64 or base64url.
4. Paste the secret into your server configuration or environment variables.

Why key size matters for JWT HMAC

The JSON Web Signature specification (RFC 7518) requires that an HMAC key be at least as long as the hash output of the chosen algorithm. If you use a shorter key, the effective security drops below the intended level. A jwt secret generator must therefore produce keys of exactly 32 bytes for HS256, 48 bytes for HS384 and 64 bytes for HS512.

For example, HS256 relies on SHA-256, which outputs 256 bits (32 bytes). Supplying a 16-byte key means an attacker only needs to search 128 bits of space rather than 256, halving the security margin. Using a key longer than the hash block size does not add meaningful strength because the algorithm hashes the oversized key down to the output length before processing.

Output encodings explained

Different frameworks expect secrets in different string formats. This tool provides three common representations so you can copy the one your library requires without manual conversion.

Hex is the most readable and avoids any padding ambiguity. Standard base64 is compact but includes + and / characters that may need escaping in URLs or configuration files. Base64url replaces those two characters with - and _ and omits trailing = padding, making it safe for HTTP headers and query strings.

How the randomness is generated

The secret bytes come from crypto.getRandomValues(), the Web Cryptography API available in every modern browser. This function draws from the operating system's cryptographic random number generator (such as /dev/urandom on Linux or BCryptGenRandom on Windows), which gathers environmental noise to maintain a high-entropy pool.

Because the generation happens entirely in JavaScript within your browser session, the raw bytes never leave your machine. No network request is made and this tool does not store the secret anywhere. This makes the jwt secret generator suitable for creating production credentials.

Storing and rotating your JWT secret

Never commit a JWT signing key to source control. Store it in an environment variable, a secrets manager such as HashiCorp Vault or AWS Secrets Manager, or an encrypted configuration file that is excluded from version control via .gitignore.

Rotate the secret periodically or immediately if you suspect exposure. During rotation, keep the old key active for a short overlap window so that tokens signed just before the change can still be verified. Once all clients have refreshed their tokens, remove the old key. You can verify existing tokens after a rotation using a jwt expiration checker to ensure none outlive the transition period.

Common mistakes to avoid

Developers frequently weaken JWT security through simple oversights. Here are the most common pitfalls:

• Using a human-readable passphrase. A phrase like "my super secret" has far fewer than 256 bits of entropy. Always use a random byte sequence from a proper jwt secret generator.
• Reusing the same key across environments. Development, staging and production should each have distinct secrets so a leak in one cannot compromise another.
• Mixing up symmetric and asymmetric algorithms. HS256, HS384 and HS512 are symmetric: the same key signs and verifies. If you need separate signing and verification keys, switch to RS256 or ES256 instead.
• Hard-coding the secret in client-side code. Any value shipped to the browser can be extracted by a user. Symmetric JWT keys belong exclusively on the server.

Worked examples