Loading Secret Key Generator…
The default answer: AES-256, HMAC-SHA256, and very nearly every field labelled API secret.
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, 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 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.
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.
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.
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.
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.
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.
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.
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.
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.