32-Character Base64 JWT Secret Generator
A 32-character Base64 secret is the standard shape for a JWT signing key in JavaScript and TypeScript backends. Because Base64 packs 6 bits into every character, this generator draws 24 raw random bytes from the Web Crypto API and encodes them URL-safely before trimming to exactly 32 characters. At 32 characters it supplies roughly 192 bits of entropy, positioning it in the "minimum" tier for HMAC-based JWT signing (HS256).
Generating…
Why 32 characters?
32 characters sits right at the security floor most standards bodies recommend for HMAC — enough to make brute-force and length-extension style guessing attacks computationally infeasible, but with no slack if your alphabet turns out to be smaller than expected.
Storage & performance: Negligible performance impact: HMAC-SHA256 hashes the key once per verification regardless of its length up to the hash's block size, so 32 bytes costs the same CPU time as 8.
Most JWT libraries accept the Base64 string as-is and treat it as a UTF-8/ASCII byte sequence — no decoding step is required before signing.
When to use / when to avoid
Use a 32-char Base64 secret when…
- You need the smallest secret that still meets HS256's security bar.
- You're prototyping locally and want a quick, copy-pasteable value.
- Your secrets manager or CI variable has a tight character limit.
Consider a different length when…
- Skip it if your framework recommends a larger default (some scaffolds ship 64+).
- Avoid if you plan to derive multiple subkeys from this single secret via HKDF.
Generate a 32-char Base64 secret in code
Each snippet below produces the same shape of secret as the tool above: a 32-character base64 string using each language's cryptographically secure RNG.
import crypto from "node:crypto";
const secret = crypto.randomBytes(24)
.toString("base64url")
.slice(0, 32);
console.log(secret); // 32 chars, URL-safe base64import base64, os
raw = os.urandom(24)
secret = base64.urlsafe_b64encode(raw).decode().rstrip("=")[:32]
print(secret) # 32-char base64url secretpackage main
import (
"crypto/rand"
"encoding/base64"
"fmt"
)
func main() {
raw := make([]byte, 24)
rand.Read(raw)
secret := base64.RawURLEncoding.EncodeToString(raw)[:32]
fmt.Println(secret) // 32-char base64url secret
}import java.security.SecureRandom;
import java.util.Base64;
byte[] raw = new byte[24];
new SecureRandom().nextBytes(raw);
String secret = Base64.getUrlEncoder().withoutPadding()
.encodeToString(raw).substring(0, 32);
System.out.println(secret); // 32-char base64url secretSecurity notes
- Generated locally with crypto.getRandomValues — nothing is sent to a server, logged, or cached.
- Regenerate before first use in production; treat any secret shown on shared screens as compromised.
- Store it in a secrets manager or git-ignored .env file, never in source control or client-side code.
- Rotate on a schedule and support at least one overlapping "next" secret to allow zero-downtime rotation.
FAQ
Why does this generator produce 32-character Base64 strings specifically?
32 characters sits right at the security floor most standards bodies recommend for HMAC — enough to make brute-force and length-extension style guessing attacks computationally infeasible, but with no slack if your alphabet turns out to be smaller than expected. The exact length is fixed at 32 so the output is deterministic to copy into configuration without manual trimming.
How many bits of entropy does a 32-character Base64 secret carry?
A–Z, a–z, 0–9, -, _ (64-symbol alphabet, padding stripped) yields about 6 bits per character, so 32 characters work out to roughly 192 bits of entropy — comfortably above the 256-bit floor commonly cited for HMAC-SHA256 keys.
Which JWT algorithm should I pair with a 32-char Base64 secret?
HS256. This is the floor RFC 7518 implies for HMAC-SHA256: 256 bits of key material, one bit per output bit of the hash.
Base64 vs. other formats at 32 characters — which should I pick?
URL-safe Base64 encoding is the most common format for HS256/HS384/HS512 JWT signing keys stored in environment variables. Most JWT libraries accept the Base64 string as-is and treat it as a UTF-8/ASCII byte sequence — no decoding step is required before signing. Pick a different format only if your framework or secrets manager has a stated preference.
Does the 32-character length affect signing or verification performance?
Negligible performance impact: HMAC-SHA256 hashes the key once per verification regardless of its length up to the hash's block size, so 32 bytes costs the same CPU time as 8.
Where should I store a 32-character Base64 JWT secret?
Use a secrets manager (Doppler, AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, 1Password) or a git-ignored .env file. Never commit it to source control, and rotate it on a schedule appropriate for HS256.
Is this 32-char Base64 secret generated securely?
Yes — it's produced entirely in your browser with the Web Crypto API's crypto.getRandomValues, a cryptographically secure PRNG. No network request is made and the value is never transmitted or logged.
Can I reuse this Base64 secret for something other than JWTs?
Yes. A 32-character Base64 string is a general-purpose high-entropy secret — it also works as an API key, session-encryption key, or CSRF token secret needing around 192 bits of randomness.
Related generators & tools
Recent articles
Guides on JWT secrets, signing algorithms, and token security.