Cryptographic Secret Key Generator

Every JWT secret, AES session key, HMAC signing key, and OAuth client secret starts the same way: a block of random bytes pulled from the operating system's cryptographic RNG. This tool exposes that primitive directly, with no server and no account, so you can generate production-quality keys in the format your stack expects without reaching for a terminal.

Pick a bit length (128, 192, 256, 384, or 512), choose an encoding, set the batch size (1 to 20), and every value is generated fresh by crypto.getRandomValues. Click Regenerate at any time to get a new set. Each key has its own Copy button, and Copy all appears when you generate a batch of two or more.

The Controls: Bit Length and Encoding

• 128-bit — 16 bytes. Minimum for AES-128 and most HMAC-SHA-256 use cases. Sufficient entropy for a session token but short enough to paste comfortably.
• 256-bit — 32 bytes. The standard choice for AES-256, JWT HS256 secrets, and general-purpose API keys. Recommended default.
• 384 / 512-bit — 48/64 bytes. Required for HMAC-SHA-384 and HMAC-SHA-512 respectively, and used in high-assurance contexts where the key must outlive current computational assumptions.
• Hex: lowercase hexadecimal, two characters per byte. Universally accepted in config files and environment variables. A 256-bit key produces 64 characters.
• Base64: RFC 4648 standard encoding with +, /, and = padding. Used in HTTP headers, PEM files, and many backend frameworks.
• Base64URL: URL-safe variant that replaces + with - and / with _, and drops padding. Required for JWT payloads, PKCE code verifiers, and any key that appears in a URL or cookie without percent-encoding.
• Base58: excludes visually ambiguous characters (0, O, I, l). Standard in wallet addresses and token identifiers where humans may need to read or type the value.

When Not to Use a Generated Key Directly

• If your framework derives a key from a passphrase (bcrypt, Argon2, PBKDF2), pass the passphrase to the derivation function rather than a pre-generated key. The KDF provides the work factor that defends against brute force; bypassing it and using a raw key removes that protection.
• Keys generated here are not SSH key pairs, TLS certificates, or RSA/ECDSA private keys. Those are asymmetric key pairs and require a different tool and format (PEM or DER).
• Never commit a secret key to a source-control repository. Store it in an environment variable, a secrets manager, or an encrypted vault. Rotate any key immediately if it is ever exposed.