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.
Nothing leaves your browser
- 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.