JWT secret generators by format & length
Twenty dedicated generators covering every common JWT signing-key shape. Pick the format your framework expects, then the length that matches your algorithm.
Every JSON Web Token signed with an HMAC algorithm (HS256, HS384, HS512) needs a shared secret, and that secret can be represented as text in several equally valid ways. This hub links to a dedicated, fully-featured generator for each combination of format (Base64, Hex, UUID, or Random String) and length (32, 64, 128, 256, or 512 characters), so you land on a page that already matches what your framework, secrets manager, and algorithm expect — instead of generating a value and then reformatting it by hand.
The right combination depends on two independent decisions: which character set your tooling can consume without extra decoding, and how many bits of entropy your security policy or HMAC variant requires. The table and guidance below walk through both.
Format comparison
| Format | Character set | Bits / char | Best for |
|---|---|---|---|
| Base64 | A–Z, a–z, 0–9, -, _ (64-symbol alphabet, padding stripped) | ~6 | Drop directly into JWT_SECRET, NEXTAUTH_SECRET, or process.env values in Node.js, Next.js, Express, NestJS, Fastify, and serverless platforms. |
| Hexadecimal | 0–9, a–f (16-symbol alphabet) | ~4 | Preferred in Go, Rust, Python, and Java codebases that decode the secret back into bytes via hex.DecodeString or similar. |
| UUID | 0–9, a–f, and literal hyphens removed before concatenation | ~3.8 | Useful when you need an opaque secret that visually resembles existing identifiers in your system, or when a config UI already expects UUID-shaped values. |
| Random String | A–Z, a–z, 0–9, and common symbols (74-symbol alphabet) | ~6.2 | Best when the secret will be transcribed by a human or pasted into a config UI that rejects '+' or '/' characters. |
Choosing a length
| Length | Recommended algorithm | Why |
|---|---|---|
| 32 | HS256 | This is the floor RFC 7518 implies for HMAC-SHA256: 256 bits of key material, one bit per output bit of the hash. |
| 64 | HS256 / HS384 | Double the HS256 minimum, giving headroom for HS384 (384-bit output) without over-provisioning. |
| 128 | HS384 / HS512 | Comfortably covers HS512's 512-bit output while remaining short enough to paste into most secret managers without truncation issues. |
| 256 | HS512 | Well beyond what HS512 requires — chosen when a security policy mandates a fixed high-entropy floor regardless of algorithm. |
| 512 | HS512 / key-derivation input | Maximum practical size for a single secret; more useful as input to a KDF (HKDF) that then derives per-purpose subkeys than as a raw signing key. |
As a rule of thumb: start at 32 characters for HS256, move to 64–128 for HS384/HS512, and reach for 256–512 only when a compliance policy demands it or when the value feeds a key-derivation function rather than being used directly as a signing key.
Base64
URL-safe Base64 encoding is the most common format for HS256/HS384/HS512 JWT signing keys stored in environment variables.
Hexadecimal
Hexadecimal output gives you a printable representation of raw random bytes — every two characters encode one byte (4 bits of entropy each).
UUID
Concatenated UUIDv4 strings, generated with crypto.randomUUID(). Each UUID supplies 122 bits of randomness.
Random String
Cryptographically random alphanumeric + symbol characters drawn from a 74-character alphabet (~6.2 bits/char).
Recent articles
Guides on JWT secrets, signing algorithms, and token security.