Secret Key Generator
Draw a random secret key for signing JWTs, webhooks and anything else that uses HMAC, in Base64 or hex and the size your algorithm asks for. It is drawn on your device and never leaves your browser.
A secret key is the shared value behind a signature — the one your app signs a JWT with and checks it against, or the one a service signs its webhooks with so you can tell a real delivery from a forged one. It is worth exactly as much as it is unguessable, so this draws one from nothing but chance, in the size your algorithm asks for and the encoding your config expects.
Your secret key
Strength: Strong, 256 bits
Customize
Each byte is 8 bits of chance, and this is the only setting that affects strength. 32 bytes is what HS256 and HMAC-SHA256 want, and what almost every JWT and webhook secret should be.
Big enough to sign with
A key larger than an algorithm asks for is fine — it gets hashed down to size — so anything above the line is covered.
Characters used
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
These 64, plus one or two = at the end to pad the key to a whole number of blocks. Strict decoders in Go and Python reject a Base64 value without it.
Key length
Worth checking against whatever holds the key — an environment variable, a secrets manager entry, a deployment config — but never a reason to drop below the size your algorithm asks for.
Recent keys
Nothing here yet. Keys you generate are kept on this device only, so you can pick one up again if you close the tab before storing it.
What makes a secret key work
One thing only: that nobody outside your systems can work it out. Every byte here is drawn separately, so 32 bytes come to exactly 256 bits. A key built from a project name, a date, a passphrase somebody chose, or a “random string” helper that quietly uses the browser's ordinary random numbers is weaker than it looks, because whoever works out the recipe can rebuild it — and a signature made with a rebuilt key looks perfectly valid.
Size follows the algorithm. HS256 signs with HMAC-SHA256, and both the HMAC specification and the JSON Web Algorithms spec ask for a key at least as long as the hash output — 32 bytes. HS384 wants 48 and HS512 wants 64. Going above the line costs nothing: HMAC hashes an oversized key down to size, so a 64-byte key signs happily with any of the three. Going below it makes the key, rather than the hash, the weakest part of the signature.
A signing key is guessed differently from a password. Nobody types it at a login form where you can slow them down; anyone holding one signed token holds a message and its signature, and can test candidate keys offline as fast as their hardware runs, with nothing to rate-limit and no way for you to see it happening. That is why 128 bits is the floor here rather than the target, and why the meter only reaches the top at 256.
The encoding is a way of writing the bytes down, not a source of strength. The same 32 bytes are 64 characters in hex and 44 in Base64 — two lengths, one level of difficulty for anyone trying to find it. Choose by what reads the key back, and leave the strength to the slider above.
Where you put it matters as much as how you drew it. A secret key belongs in an environment variable or a secrets manager, never in the repository, a front-end bundle, a log line or an error report — and it is worth being able to replace one on short notice, so accept both the old and the new key for a short window while everything catches up. Give each service and each environment its own, so one leak does not become all of them.
Nothing here is registered with anyone. A key becomes real only when you store it and start signing with it, so generating another is the whole cost of losing one before then.
Everything happens on your device. Your secret keys never leave this browser.