JWT Secret Generator
Generate a cryptographically secure random secret for signing JSON Web Tokens via HMAC-SHA256/384/512.
Security note
Never hardcode this secret in source code. Store it in an environment variable (e.g. JWT_SECRET) and load it at runtime. Rotate secrets immediately if they are ever exposed. Generated locally — never transmitted.
How to choose a JWT signing secret
JSON Web Tokens signed with HMAC (HS256/HS384/HS512) require a shared secret. The security of your tokens depends entirely on the strength of this secret. NIST recommends at least 256 bits of entropy for HMAC-SHA256 keys. This tool generates secrets with crypto.getRandomValues, which draws from your operating system's hardware entropy pool — far stronger than Math.random(). Always use a unique secret per environment (development, staging, production) and never share secrets across services.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Producing a signing secret for a new service rather than inventing a memorable string.
- Generating separate secrets per environment so a staging token cannot be replayed against production.
- Rotating a secret that has appeared in a repository or a log.
- Producing a secret sized to the hash you are actually using rather than a round number.
- Creating a value in the encoding your configuration format handles cleanly.
Frequently Asked Questions
- How long should an HMAC signing secret be?
- At least as long as the hash output — RFC 7518 §3.2 requires a key of at least 256 bits for HS256, 384 for HS384 and 512 for HS512, and says a key smaller than that MUST NOT be used. A short memorable passphrase is the classic failure: it can simply be brute-forced offline from one captured token.
- Does switching the output format change the secret?
- No. The bytes are the secret and the encoding is a view of them, so flipping Base64url to Hex shows the same value written differently. Regenerating is an explicit button — otherwise someone who copied one form and then changed the dropdown to check it would be holding two unrelated secrets.
- Why do the three formats have such different lengths?
- They carry identical entropy. A 256-bit secret is 32 bytes: 64 hex characters, 44 base64 with one = of padding, or 43 as base64url with padding stripped. The 384-bit size is the tidy one — 48 bytes divides evenly by three, so its base64 form is exactly 64 characters with no padding at all.
- Is a 512-bit secret better than 256 for HS256?
- Marginally, and it stops helping quickly. HMAC-SHA256 has a 512-bit block, so a 512-bit key is used as-is; anything longer is hashed down to 32 bytes first, so a 1024-bit secret is no stronger than a 256-bit one. Match the secret to the algorithm rather than reaching for the largest number.
- Can I use the same secret across environments?
- No — a leaked staging secret then mints valid production tokens, and staging is usually the softer target. Generate one per environment, store it as an environment variable rather than in source, and treat exposure as requiring immediate rotation, which invalidates every token already issued.
Common errors and gotchas
- Using a short or memorable secret, which makes the signature forgeable by brute force and defeats the whole scheme.
- Sharing one secret across environments, so any leak from the least protected one compromises the rest.
- Choosing a secret shorter than the hash output, which throws away security the algorithm would otherwise provide.
- Reading the format change as a different secret. The three encodings represent the same underlying bytes.
- Committing the secret to the repository alongside the code that uses it.