JWT Secret Generator

Generate a strong random secret key for signing JSON Web Tokens with the HMAC algorithms HS256, HS384 or HS512. Pick a key size — 256, 384 or 512 bits, matching the algorithm you'll use — and get the same random bytes encoded as hex, base64 and base64url, so you can drop it straight into whatever your library or config expects. The bytes come from your browser's cryptographically secure random generator and never touch the network.

How to use the JWT Secret Generator

Choose a key size to match the algorithm you'll sign with — 256 bits for HS256, 384 for HS384, 512 for HS512 — and press Generate new secret. The tool draws that many random bytes from the Web Crypto secure generator and shows them in three encodings at once. Use whichever your stack wants: many JWT libraries take the secret as a raw or base64 string, environment variables usually hold hex or base64url, and base64url is the URL-safe variant that avoids +, / and =. All three encode the identical underlying bytes, so the choice is purely about format.

Copy the value into your secret store — an environment variable, a secrets manager, your platform's config — never into source code or a public repository. Because the secret is generated locally and not saved, regenerating gives you a brand-new key and the previous one is gone. The 256-bit minimum is deliberate: HMAC-SHA256 keys should be at least as long as the hash output (32 bytes) so the key has full entropy, which is why these sizes are tied to the algorithms. A short or low-entropy secret is the most common reason HMAC-signed tokens get forged, so prefer a generated value like this over a memorable passphrase.

Why JWT signing secrets must be strong

A JSON Web Token signed with an HMAC algorithm — HS256, HS384 or HS512 — is protected by a single shared secret. The issuer computes a keyed hash over the token's header and payload, appends it as the signature, and any party that holds the same secret can recompute the hash to verify the token hasn't been tampered with. Unlike the asymmetric RS/ES algorithms, where a private key signs and a separate public key verifies, the HMAC family uses the same secret for both, which makes it simple and fast but means that secret is the only thing standing between your system and forged tokens.

That is why the quality of the secret matters so much. If an attacker can guess or brute-force it, they can mint tokens with any claims they like — any user ID, any role, any expiry — and your server will accept them as genuine. Weak secrets are a well-documented JWT failure mode: short strings, dictionary words, reused application secrets and copied-from-a-tutorial values have all been cracked offline, because an attacker who captures one valid token can test candidate keys against it at billions of guesses per second. The defence is entropy. A secret of random bytes, at least 256 bits long, has so many possible values that brute force is hopeless regardless of how much compute an attacker brings.

The recommended sizes follow the algorithm. HMAC-SHA256 produces a 256-bit output, so the key should be at least 256 bits (32 bytes) of real randomness to match it; HS384 and HS512 scale up accordingly. There's no benefit to a memorable secret here — nobody needs to type it — so it should be machine-generated from a cryptographically secure source, exactly what this tool does. Store it the way you'd store a database password: in an environment variable or secrets manager, out of version control, rotated if it's ever exposed. And remember the shared-secret caveat: every service that verifies the token must hold the secret, so if many parties need to verify but only one should sign, an asymmetric algorithm like RS256 or ES256 is the better fit.

Common use cases

  • API authentication. Generate the signing secret for HS256/384/512 JWTs in a new service.
  • Secret rotation. Produce a fresh high-entropy key when rotating an exposed or ageing secret.
  • Local and CI config. Fill JWT_SECRET environment variables for development and test environments.
  • General-purpose keys. Get random bytes in hex/base64 for any HMAC or symmetric-key use.

Frequently asked questions

What key size should I use?
Match it to your algorithm: 256 bits for HS256, 384 for HS384, 512 for HS512. The key should be at least as long as the hash output so it has full entropy, which is why HMAC-SHA256 keys should be a minimum of 256 bits (32 bytes).

Which encoding do I paste into my config?
Whichever your library expects — they all encode the same random bytes. Many JWT libraries accept a base64 or raw string; base64url is the URL-safe form without +, / or =. If your library treats the secret as a literal string, be consistent about which encoding you store and use everywhere.

Is the secret generated securely?
Yes. The bytes come from the Web Crypto API's cryptographically secure pseudo-random generator (crypto.getRandomValues), the same source browsers use for real cryptographic operations. Generation happens locally and the value is never sent over the network.

When should I use RS256 or ES256 instead?
HMAC (HS*) uses one shared secret for both signing and verifying, so anyone who can verify can also sign. If multiple parties need to verify tokens but only one should issue them, use an asymmetric algorithm like RS256 or ES256, where a private key signs and a public key verifies.

Should I store this in my code?
No. Treat it like a password: put it in an environment variable or a secrets manager, keep it out of version control, and rotate it if it is ever exposed. Hard-coding a JWT secret in source — especially a public repository — is a common cause of token forgery.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: