0 bits of entropy
Key size
Encoding
Generate random AES-128, AES-192 or AES-256 encryption keys in Hex or Base64, directly in your browser.
Press Space for a new key, C to copy. Generated with crypto.getRandomValues on your own device.
For a 256-bit encryption key in Hex, keep 256-bit and Hex selected, then copy the generated key. This gives you 32 random bytes written as 64 hexadecimal characters. For a 128-bit key, select 128-bit instead. Choose Base64 if your application requires it; the table shows encoded lengths including Base64 padding.
| AES key | Random bytes | Hex characters | Base64 characters |
|---|---|---|---|
| AES-128 | 16 | 32 | 24 |
| AES-192 | 24 | 48 | 32 |
| AES-256 | 32 | 64 | 44 |
An AES key is a fixed block of random bytes: 16 for AES-128, 24 for AES-192, 32 for AES-256. Unlike a password there is no minimum or maximum to weigh up — the algorithm takes one of exactly three lengths, and every bit of it has to be unguessable.
The bytes come straight from crypto.getRandomValues, the browser's cryptographically secure random number generator, and are then written out as hexadecimal or Base64. No timestamp, no counter, and no Math.random anywhere in the path. Both spellings carry the same bytes; pick the one your library or key store wants.
The key is generated and kept in your browser. Reloading the page clears it.
Match the key size required by your application or encryption library. AES-128 needs 16 random bytes, AES-192 needs 24, and AES-256 needs 32. This generator defaults to AES-256. Select 128-bit or 192-bit when your system requires that size, and choose the output encoding it expects.
Not necessarily: characters describe the encoded text, while bytes describe the key itself. A 32-character Hex string decodes to 16 bytes, which is an AES-128 key. A 32-byte AES-256 key needs 64 Hex characters or 44 characters in padded Base64. If an application asks for 32 characters, check whether it expects literal text, Hex or Base64 before copying a key.
No. The key is a long-lived secret. The IV (or nonce in GCM) is a per-message value that is not secret at all and is normally transmitted in the clear alongside the ciphertext. Generate a fresh IV for every message; generate a key once and keep it.
No. One key can encrypt many messages, but GCM requires a unique nonce for every encryption under that key. Reusing a nonce leaks information about the plaintexts and can enable message forgery. Random 96-bit nonces are common, but collisions remain possible: enforce the per-key usage limits of your protocol or cryptographic library, and rotate the key before reaching them. Random generation does not guarantee uniqueness.
Not directly. A password is short and drawn from a small space; an AES key must be indistinguishable from random. If a human has to remember the input, run it through a key derivation function — Argon2id, scrypt, or PBKDF2 with a high iteration count — and use the output as the key. Hashing a password once with SHA-256 gives you 32 bytes, but not 32 bytes of unpredictability.
GCM, in almost every case. It authenticates as well as encrypts, so tampering with the ciphertext is detected rather than silently decrypted into garbage that your code then trusts. CBC on its own provides no integrity at all and has to be paired with a separate MAC, applied in the right order, which is exactly the kind of detail that goes wrong quietly.
Use the format your application expects. Hex and Base64 represent the same random bytes and do not change the key's strength. A 32-byte AES-256 key is 64 Hex characters or 44 characters in padded Base64. Decode the copied text to bytes if your library expects a byte array; passing the encoded string directly may give it the wrong key length.
In a key management service if you have one, otherwise an environment variable or a secrets file that is not in version control. Never beside the ciphertext it protects — a key stored in the same database, backup, or repository as the data offers no protection once that store is copied. Note also that rotating an AES key means re-encrypting the data, which is why rotation needs planning rather than a cron job.