0 bits of entropy
Key size
Encoding
Random AES keys for 128, 192 and 256-bit encryption, generated in your browser. No network, no logs, nothing uploaded.
Press Space for a new key, C to copy. Generated with crypto.getRandomValues on your own device — this page loads nothing from the network.
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.
Everything happens on your own device. The page makes no network requests after it loads, so this key has never existed anywhere else and never travels. Reload and it is gone.
AES-256 unless something forces your hand, not because 128 is breakable but because the larger key costs almost nothing and removes the question from future arguments. AES-128 remains entirely secure against brute force and is measurably faster on hardware without AES acceleration. AES-192 exists, is fine, and is used so rarely that some libraries and hardware paths handle it worse than the other two.
No — the difference is 2^128 times larger, not two times. Both numbers are past the point where brute force means anything: counting to 2^128 is beyond what the energy budget of the planet allows, whatever hardware you imagine. Key size is not where real systems fail. Reused nonces, keys derived from passwords, and keys stored beside the data they protect are.
No, and confusing the two is the single most common AES mistake. 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 encrypts many messages, provided each message gets its own IV or nonce. What must never repeat is the nonce under the same key — in GCM, reusing one leaks the XOR of two plaintexts and lets an attacker forge messages, which is a total break rather than a small weakening. A random 96-bit nonce per message is the usual way to guarantee it.
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.
The same bytes either way — a 256-bit key is 64 hex characters or 44 Base64 characters, with identical strength. Use the format the receiving system expects: cloud key stores and language libraries commonly want Base64, while config files, CLI flags and anything passing through a shell are safer in hex, which contains nothing but 0-9 and a-f.
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.
Only if the page cannot transmit it, and that is checkable rather than something you have to take on faith. Open developer tools, sit on the Network tab, and generate as many keys as you like: nothing is requested after the page loads. There is no server behind this to receive anything, and no analytics or third-party script to leak it.