64-Character Random String JWT Secret Generator
This 64-character secret is sampled uniformly from a 74-symbol alphabet covering uppercase, lowercase, digits, and common punctuation. It's the best choice when a human will read, transcribe, or paste the value into a UI that rejects Base64's '+' and '/' characters. At 64 characters it supplies roughly 397 bits of entropy, positioning it in the "comfortable" tier for HMAC-based JWT signing (HS256 / HS384).
Generating…
Why 64 characters?
64 characters roughly doubles the 32-character floor, absorbing any entropy loss from a smaller alphabet (like UUID's hex-only character set) while still being short enough to read at a glance in a .env file.
Storage & performance: Still well under SHA-256's 64-byte block size, so HMAC computes the key schedule in a single pass with no extra hashing overhead.
Random strings are used verbatim as the HMAC key material — no decoding step, which makes them the simplest format to reason about in any language.
When to use / when to avoid
Use a 64-char Random String secret when…
- You want headroom above the bare HS256 minimum without a bulky value.
- Your team standardizes on one secret length across HS256 and HS384 services.
- You're rotating an existing 32-char secret and want a stronger replacement.
Consider a different length when…
- Skip it if a compliance policy mandates a specific higher bit count.
- Not ideal if you're deriving several purpose-specific keys from one master secret.
Generate a 64-char Random String secret in code
Each snippet below produces the same shape of secret as the tool above: a 64-character random string string using each language's cryptographically secure RNG.
import crypto from "node:crypto"; const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~!@#$%^&*"; const bytes = crypto.randomBytes(64); let secret = ""; for (let i = 0; i < 64; i++) secret += alphabet[bytes[i] % alphabet.length]; console.log(secret); // 64-char random string
import secrets
alphabet = (
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~!@#$%^&*"
)
secret = "".join(secrets.choice(alphabet) for _ in range(64))
print(secret) # 64-char random stringpackage main
import (
"crypto/rand"
"fmt"
"math/big"
)
const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~!@#$%^&*"
func main() {
out := make([]byte, 64)
for i := range out {
n, _ := rand.Int(rand.Reader, big.NewInt(int64(len(alphabet))))
out[i] = alphabet[n.Int64()]
}
fmt.Println(string(out)) // 64-char random string
}import java.security.SecureRandom;
String alphabet =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~!@#$%^&*";
SecureRandom random = new SecureRandom();
StringBuilder sb = new StringBuilder(64);
for (int i = 0; i < 64; i++) {
sb.append(alphabet.charAt(random.nextInt(alphabet.length())));
}
String secret = sb.toString();
System.out.println(secret); // 64-char random stringSecurity 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 64-character Random String strings specifically?
64 characters roughly doubles the 32-character floor, absorbing any entropy loss from a smaller alphabet (like UUID's hex-only character set) while still being short enough to read at a glance in a .env file. The exact length is fixed at 64 so the output is deterministic to copy into configuration without manual trimming.
How many bits of entropy does a 64-character Random String secret carry?
A–Z, a–z, 0–9, and common symbols (74-symbol alphabet) yields about 6.2 bits per character, so 64 characters work out to roughly 397 bits of entropy — well above the 256-bit floor commonly cited for HMAC-SHA256 keys.
Which JWT algorithm should I pair with a 64-char Random String secret?
HS256 / HS384. Double the HS256 minimum, giving headroom for HS384 (384-bit output) without over-provisioning.
Random String vs. other formats at 64 characters — which should I pick?
Cryptographically random alphanumeric + symbol characters drawn from a 74-character alphabet (~6.2 bits/char). Random strings are used verbatim as the HMAC key material — no decoding step, which makes them the simplest format to reason about in any language. Pick a different format only if your framework or secrets manager has a stated preference.
Does the 64-character length affect signing or verification performance?
Still well under SHA-256's 64-byte block size, so HMAC computes the key schedule in a single pass with no extra hashing overhead.
Where should I store a 64-character Random String 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 / HS384.
Is this 64-char Random String 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 Random String secret for something other than JWTs?
Yes. A 64-character Random String string is a general-purpose high-entropy secret — it also works as an API key, session-encryption key, or CSRF token secret needing around 397 bits of randomness.
Related generators & tools
Recent articles
Guides on JWT secrets, signing algorithms, and token security.