b2KIT

Secret Key Generator

Generate cryptographically secure secret keys for JWT signing, HMAC, AES encryption, and other applications.

Tested tool guide Tested browser tools Checked August 16, 2026

What Secret Key Generator does and how it behaves

This tool draws random bytes from a cryptographically secure source in your browser and turns them into a secret key in the form your application expects. Nothing is transmitted, so the key exists only on your machine until you copy it. The thing most users get wrong is size: a short, human-friendly key comes in below what the algorithms expect. JWT HS256 and AES-256 both call for 256-bit keys - 32 bytes, which is 64 hex characters or 43 base64url characters - while a random 16-character alphanumeric string carries only about 95 bits of entropy. A secret key is also symmetric: you generate one and share it with every party that must verify or decrypt.

How the result is produced

1

Where the randomness comes from

The browser's built-in cryptographically secure random generator supplies the bytes - the same class of source browsers rely on for TLS and Web Crypto operations, not a time-seeded pseudorandom routine. Each bit is independent, so a key of n bits carries n bits of entropy, and the exact moment you clicked Generate reveals nothing about the result. Generation is local: the key is never transmitted, logged, or stored anywhere.

2

What length and encoding actually mean

A key's strength is its byte count; the encoding is just how the bytes are written. Hex writes two characters per byte, so 32 bytes become 64 characters. Base64 and base64url write four characters per three bytes, so 32 bytes become 44 characters with padding, or 43 with base64url padding stripped - the form JWT requires. A prettier display of the same bytes adds no security.

Good uses

  • Creating the signing secret when you first set up JWT authentication for a service: generate 32 bytes (256 bits), store the value in a secrets manager or .env file, and put the same value in every process that issues or verifies tokens.
  • Producing an AES-256 key before encrypting data at rest - a database column, a backup archive, or files exchanged between services - where the identical 256-bit key must exist on both the encrypting and the decrypting side.
  • Rotating a secret after a suspected leak or on a scheduled cycle: generate a fresh key, update every consumer, and keep the old key valid long enough for tokens or data encrypted under it to expire or be re-encrypted.

Limits and checks

  • Character count and byte count are different: 64 hex characters is a 32-byte (256-bit) key, but 64 base64 characters is 48 bytes (384 bits). If the tool asks for characters rather than bits or bytes, convert before you choose, or you may undersize or oversize the key relative to what your library expects.
  • A secret key is one shared symmetric value, not a key pair. There is no public part and no one-way verification: every party that must validate tokens or decrypt data needs the same secret, and anyone who holds it can forge and decrypt. If you must sign without sharing the signing material, you need an asymmetric key pair instead.
  • There is no recovery and no built-in check. Because generation is local and random, nothing stores a backup, and a mistyped or truncated copy fails silently at verify or decrypt time - the error message will not tell you the key is wrong. Keep the key in a secrets manager rather than ad-hoc text files.

Common questions

Can I use a shorter key or a passphrase I can remember?

For HS256 and AES-256, no. RFC 7518 requires HS256 keys of at least 256 bits, and AES-256 is defined around exactly 256. Human-chosen passphrases fare worse than their length suggests, because people pick predictable words and patterns. Keys are configuration, not something to memorize: generate 256 bits, store them in a secrets manager or .env file, and let the software read them.

Is it safe to paste the generated key into a chat message to share with a teammate?

No. The tool keeps the key local while generating it, but the moment you paste it into chat, an email, or a commit, you have exposed a secret that lets anyone holding it forge tokens or decrypt data, and you cannot take it back. Share keys only through a secrets manager or an access-controlled channel, and rotate if a key ever touches an unapproved one.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools