How Secret Key Generation Works and Why Math.random Is Unsafe
A secret key generator produces cryptographically random strings suitable for API keys, JWT signing secrets, session secrets, encryption keys, and other credentials that software systems need but humans never have to memorize or type. Unlike a password, nobody needs to recall a secret key from memory, so the only requirements are unpredictability and sufficient length. Developers configuring a new backend service, setting environment variables like NEXTAUTH_SECRET for a web app, or rotating a webhook signing secret after a security incident are the typical audience for a tool like this, because generating a genuinely random key correctly is harder than it looks.
The generator fills a byte array of the chosen length using crypto.getRandomValues, the same cryptographically secure random number source browsers use for generating TLS session keys, then encodes those raw bytes into the requested output format: hex (two characters per byte), standard base64, URL-safe base64url with plus and slash replaced and padding removed, or a custom alphanumeric alphabet. The alphanumeric encoding uses rejection sampling rather than a plain modulo on each random byte, since modulo would bias the output toward earlier characters in the alphabet whenever the byte range is not an exact multiple of the alphabet's length. A 256-bit key, the most common size here, is exactly 32 random bytes, which becomes 64 hexadecimal characters, roughly 44 base64 characters including padding, or 43 base64url characters without it.
Generating a 256-bit key for use as a NEXTAUTH_SECRET, one of the built-in presets, produces 32 random bytes and encodes them as base64, yielding a 44-character string ending in a single padding character that you paste directly into a .env file. Choosing the encryption-key preset instead outputs the same 256 bits of entropy as 64 hexadecimal characters, since hex is the conventional format most crypto libraries expect when configuring AES-256, which needs exactly 32 bytes of key material. A UUIDv4, generated separately via crypto.randomUUID, looks structurally different and packs only 122 truly random bits because four bits are fixed to mark the version and two more mark the variant, so it should not be treated as equivalent to a full 128-bit random key.
Backend developers setting up a new Express or Next.js project need a JWT signing secret or NEXTAUTH_SECRET before their authentication flow will even start, and generating one here in base64 or hex format, then pasting the .env-ready output line directly into a config file, skips the error-prone step of typing a random-looking string by hand, which is often not random at all. Teams rotating a webhook signing secret after a partner integration is decommissioned, or after a suspected leak, generate a fresh hex-encoded key and update both sides of the integration simultaneously, since a webhook signature check fails safe by rejecting the payload if the secrets do not match. Anyone configuring self-hosted software that asks for a session secret or encryption key in its setup wizard can generate several candidates at once and pick the size the documentation specifies.
Never use Math.random to generate a secret: it is a fast, statistically-fine random number generator for animations and games, but it is not cryptographically secure, meaning its internal state can sometimes be reconstructed from observed outputs, which is disastrous for a value meant to be unguessable. Store generated secrets in environment variables or a dedicated secret manager, never committed into a Git repository, not even a private one, since repository history is permanent and secrets committed once are considered compromised even after deletion; rotate them periodically and immediately after any suspected exposure. Everything on this page runs through the Web Crypto API locally in your browser, with no key ever transmitted or stored anywhere, so each key you generate is yours alone the moment it appears.
