JWT Secret Generator (HS256 / HS512)
Signing keys for JWT HMAC algorithms — 256-bit for HS256, 512-bit for HS512.
$ openssl rand -base64 32
Why your JWT secret must be random
HS256 signs tokens with HMAC-SHA-256, and RFC 7518 requires a key of at least 256 bits for it. A human-chosen string like mysecretkey123 has a tiny fraction of that entropy, and offline brute-forcing of weak HS256 secrets is a routine attack: anyone holding one of your tokens can crack the secret on a GPU, then forge admin tokens at will. The fix is simple — use a full-entropy random key.
HS256 or HS512?
This tool generates 32 random bytes (256 bits) for HS256 or 64 bytes (512 bits) for HS512, encoded as base64url. HS256 with a random 256-bit key is not a practical weak point; pick HS512 only for policy reasons or because the rest of your stack is on SHA-512. If tokens are verified by many services, consider an asymmetric algorithm (RS256/EdDSA) instead, so verifiers never hold the signing key.
Handling the secret
Store it in an environment variable or secret manager — never in the repository — and rotate it if you suspect exposure (rotation invalidates outstanding tokens). The secret is generated by crypto.getRandomValues() on your device; it never leaves your browser, is never logged and never stored.
How long should a JWT secret be?
At least 256 bits (32 bytes) for HS256 and 512 bits (64 bytes) for HS512 — RFC 7518 requires a key at least as long as the hash output. This page generates exactly that. A human-chosen string like mysecretkey123 has a tiny fraction of that entropy.
HS256 or HS512?
HS256 with a random 256-bit key is not a practical weak point — pick HS512 only for policy reasons or because the rest of your stack is on SHA-512. The more useful question is symmetric versus asymmetric: if tokens are verified by several services, use RS256 or EdDSA instead, so verifiers never hold the key that can also sign.
What happens if my JWT secret is weak?
Anyone holding one of your tokens can brute-force the secret offline on a GPU, then forge tokens with any claims they like — including admin. This is a routine attack, not a theoretical one, and it is silent: nothing in your logs shows it happening. A full-entropy random key removes the attack entirely.
I'm getting IDX10603: the algorithm requires a key size larger than 128 bits.
That .NET error means your signing key is shorter than HS256 requires — paste the HS256 value above into your configuration. The full explanation, including why .NET measures UTF-8 bytes so a short passphrase fails even when it looks complicated, is on our guide: how long should a JWT secret be.
Nothing leaves your browser
- Don't take our word for it — turn off your wifi. Every generator on this site keeps working with the network disconnected. That's the whole proof, and it takes five seconds.
- Every value comes from
crypto.getRandomValues()— the CSPRNG built into your browser, neverMath.random(). - Generated secrets are never transmitted, logged or stored: no server-side generation, no cookies, no localStorage.
- Verify it yourself in the network tab: after loading, the page only talks to our self-hosted, cookie-less analytics — which counts page views and which generator type gets copied, never any value.
- Strict Content-Security-Policy; no third-party script origins.
All generators
- Base64 Secret Generator
- UUID Generator
- Password Generator
- Hex Secret Generator
- Passphrase Generator
- SSH Key Generator (Ed25519)
- PIN Generator
- WireGuard Key Generator
- API Key Generator
- TOTP Secret Generator
- Django SECRET_KEY Generator
- Laravel APP_KEY Generator
- NextAuth Secret Generator
- Flask SECRET_KEY Generator
- Rails secret_key_base Generator
- Strapi APP_KEYS Generator
- ULID Generator
- Nano ID Generator