Cryptographic Key Generator

// Generate the byte length your cryptographic contract expects

Cryptographic material is bytes first and text second. Choose the operation you are configuring and this generator sets the exact byte length: 16, 24, or 32 bytes for AES-128, AES-192, or AES-256, plus practical digest-sized presets for HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. A custom mode covers protocols with a different documented requirement.

The HMAC sizes are useful defaults, not a rule that every HMAC key must equal its hash output length. Your library or protocol remains the authority. For AES, the three named key sizes come directly from the AES standard; a 512-bit random value is not an AES-512 key because AES-512 does not exist.

Every result comes from crypto.getRandomValues in this browser. There is no Math.random fallback. If the secure source is unavailable or fails, the page returns no replacement and says so.

// A key, IV, nonce, and salt have different jobs

A symmetric key or HMAC key is secret material. Anyone who obtains it may be able to decrypt data or create valid authentication tags, so move it into a secrets manager or other protected configuration and rotate it if it leaks.

An IV or nonce is supporting input to an encryption mode. It normally travels with the ciphertext rather than being hidden, but it must follow that mode's uniqueness and generation rules. Reusing a nonce with the same AES-GCM key can break the security of the encrypted data. The AES-GCM preset is 12 bytes; the AES-CBC IV preset is one 16-byte AES block.

A password salt is also not a secret key. Give every password hash a unique salt and store it with the hash. Modern password-hashing libraries commonly create and manage salts themselves, so use this preset only when your chosen API explicitly asks you to supply the bytes.

// Hex, Base64, Base64url, and byte arrays are views of the same value

Changing the output format does not create a new key. Hex uses two characters for every byte. Base64 is shorter but can contain plus, slash, and equals characters. Base64url replaces the first two and removes trailing padding so the value fits more safely in URLs and filenames. The byte-array view shows the underlying decimal values directly.

Copy the format your consuming library documents. Do not measure security by the number of visible characters: a 32-byte value still carries 256 generated bits whether it appears as 64 hex characters, 44 padded Base64 characters, or a list of 32 decimal bytes.

// Generate locally, then handle the result like a real secret

Generated values live only in this tab's memory. They are not sent to a generation endpoint, placed in a URL, written to localStorage, or added to a saved history. You can inspect the browser Network panel while generating or load the page before disconnecting to verify that boundary.

Local generation removes one server from the path, but it cannot make an untrusted device safe. Browser extensions, clipboard history, screen sharing, source control, logs, and chat messages can all expose a copied key. Prefer a secrets manager for production material, restrict access to the systems that need it, and replace any value whose handling is uncertain.

// fair questions

Is it safe to generate a cryptographic key online?

It is safer when generation happens locally and the value is never transmitted or retained. This page uses crypto.getRandomValues in your browser and stores no history. A compromised device, browser extension, clipboard manager, screenshot, or pasted message can still expose the result, so use a trusted device and move production keys directly into protected storage.

Which AES key size should I choose?

Choose the size required by the system you are configuring. AES defines 128-, 192-, and 256-bit keys, equal to 16, 24, and 32 bytes. This generator defaults to AES-256, but a larger key does not repair an unsafe encryption mode, a reused nonce, exposed storage, or broken key rotation.

Is an IV or nonce the same as an encryption key?

No. The key must remain secret. An IV or nonce is usually stored or sent with the ciphertext, but it must satisfy the selected mode's rules. In particular, never reuse a nonce with the same AES-GCM key. Generate a fresh supporting value for each operation unless your protocol specifies another construction.

Should a password salt be kept secret?

No. A salt should be unique for each password hash and is normally stored beside that hash. It prevents attackers from reusing one precomputed table across many passwords. Do not substitute a salt for a secret pepper or an encryption key, and let your password-hashing library manage salts when it already does so.

Does converting a key from hex to Base64 change it?

No. Hex, Base64, Base64url, and the decimal byte array encode the same bytes. Switching the format on this page does not regenerate the material, so you can compare or copy the representation your library expects without changing the underlying key.

Are generated keys saved anywhere?

No. They exist in this tab's memory only and are not written to localStorage, cookies, URLs, analytics, or a generated-value history. Regenerating replaces them; refreshing or closing the page loses them. Save the result in its intended secrets manager before leaving.