Secret Key Generator
The default answer: AES-256, HMAC-SHA256, and very nearly every field labelled API secret.
No key yet.
How this was worked out
- Bytes drawn256 ÷ 8 = 32 bytes, taken from crypto.getRandomValues — never Math.random, which is seeded and predictable
- Written as hextwo characters a byte = 64 characters (RFC 4648 §8)
- Written as base64four characters per three bytes = 44 characters padded, 43 unpadded in the URL-safe alphabet (§4 and §5)
- Written as base32eight characters per five bytes = 56 characters (§6)
- Same key throughoutone draw of bytes shown four ways — the encodings convert into each other exactly, so nothing here is four keys
Every encoding above is the same key. One draw of 32 random bytes, written four ways, so a library that wants base64url and a config file that wants hex can be given the same secret without generating it twice. Choose the form the other side specifies and ignore the rest: re-encoding the 4 values into each other is lossless, but pasting hex where base64 was expected silently halves the key.
This is a random key, not a password and not a key derived from one. It cannot be remembered and it is not meant to be typed — put it in a secrets manager or an environment variable, never in a repository. Nothing here is stored or transmitted and nothing goes in the address bar, which also means nothing here can be recovered: close the tab and the key is gone. Rotate on the schedule the service you are calling asks for, and treat a key that has appeared in a log, a screenshot or a chat message as already public.
The bit count is the whole of the claim, and it holds only because the bytes come from the operating system’s cryptographic generator through crypto.getRandomValues. A 256-bit key is 256 bits of randomness whichever encoding you copy; what it is not is 64 characters of strength, because hex characters carry four bits each and nothing about the longer string adds anything to the shorter one.
A key is not a password
The values this tool produces are meant for machines. An API secret, an HMAC signing key, a session-cookie key or a JWT symmetric key is read from a configuration file or an environment variable, never typed, and never derived from something a person invented. That is what lets it be full-strength random rather than something anybody has to hold in their head.
The practical consequence is that none of the usual password advice applies. There is nothing to make memorable, no benefit to a mnemonic, and no reason to prefer one form of the value over another except what the library on the other side expects.
Choosing a length
For a symmetric key the length should match the algorithm using it. AES takes 128, 192 or 256 bits. For HMAC, RFC 2104 discourages a key shorter than the digest it is paired with, so SHA-256 wants at least 256 bits, and a key longer than the hash block size is silently hashed down before use — which makes a 1024-bit HMAC key a slower way of having a 512-bit one.
Where nothing specifies a length, 256 bits is the right default and 128 is a defensible floor. Beyond 256 the gains are theoretical: no attacker is exhausting a 128-bit space with any hardware that exists, and doubling the number does not double anything an adversary has to do.
Four ways of writing the same bytes
One draw of random bytes is shown in four encodings from RFC 4648. Hex is two characters a byte and always even in length. Standard base64 is more compact but uses plus, slash and equals, all of which mean something else in a URL or a filename. Base64url swaps in hyphen and underscore and drops the padding, which is the form JWTs and query parameters use. Base32 is upper case with the digits 2 to 7, avoiding every character that reads as another.
A 256-bit key is 64 hex characters, 44 standard base64 characters, 43 base64url or 56 base32. Those lengths are the quickest way to tell what a field is expecting. Pasting hex where base64 was wanted is the classic error: the library decodes it happily and ends up with a key of half the intended strength, with no error message anywhere.
Where the randomness comes from, and where it goes
Every byte is drawn from the browser’s own cryptographic generator through crypto.getRandomValues, which is seeded by the operating system. Math.random appears nowhere: it is fast, reproducible and predictable from a handful of outputs, which is harmless for a shuffle and disqualifying for a secret.
Generation happens in the page, with no request to any server and nothing written to storage, so the key exists only in this tab and wherever you paste it. That also means it cannot be recovered — close the tab before saving it and the value is gone for good. Put it straight into a secrets manager or an environment variable, keep it out of the repository, and treat any key that has appeared in a log, a screenshot or a chat message as public from that moment.
What it cannot generate
Everything here is symmetric: a single value that both sides hold. A key pair is a different object altogether. An RSA or Ed25519 private key has internal mathematical structure and is produced by ssh-keygen, openssl or a library call, not by drawing random bytes — so if a service is asking for a public key, nothing on this page will satisfy it.
Nor is this a key derivation function. Turning a password into a key is the job of PBKDF2, scrypt or Argon2id, which are deliberately slow and take a salt; expanding one key into several is the job of HKDF. Both transform material you already have, which is the opposite of what a generator does.
Encodings, key length and rotation
Which encoding should I paste?
Whichever the documentation on the other side names. If it says nothing, hex is the safest guess for a configuration file and base64url for anything travelling in a URL. Never convert between them by hand halfway through a deployment.
Is a 512-bit key twice as strong as a 256-bit one?
No. It doubles the storage and adds nothing an attacker would notice, since both are far beyond exhaustive search. Longer keys matter only when a specification asks for one, such as HMAC paired with SHA-512.
Can I use one of these as a password?
You can, but you will not enjoy it, and it is the wrong tool. A password gets typed and sometimes remembered, so a passphrase serves better. Use these where software reads the value and no human ever does.
How often should a key be rotated?
On whatever schedule the service you are calling publishes, and immediately on any suspicion of exposure. Rotation is only useful if the old key is actually revoked afterwards, which is the step most often forgotten.
Where should the key actually live?
In a secrets manager, or in an environment variable set by the deployment, and never in the repository — a key committed once stays in the history long after it is deleted from the file.
Do I need a different key for each environment?
Yes. Sharing one between staging and production means anything leaking out of the looser environment unlocks the stricter one, and rotating either becomes an outage in both.