Random String Generator

You need a 32-character random string for a session key, or a quick batch of unique IDs for testing. Pick a length, pick a character set (alphanumeric, hex, base64-safe, custom), and generate one or many at once.

The generator uses cryptographically secure randomness (`crypto.getRandomValues` under the hood), which matters for anything security-adjacent. A predictable PRNG can produce strings that look random to humans but are guessable for an attacker — this avoids that.

Generated strings stay in your browser. Use them for keys, salts, test fixtures, or whatever else needs a chunk of random text. For password generation specifically, the dedicated password-generator tool has rules around character requirements that this one doesn't enforce.

The generator pulls bytes from `crypto.getRandomValues`, the browser's cryptographically secure pseudorandom number generator. Unlike `Math.random()`, which uses an algorithm with predictable internal state, the CSPRNG uses entropy from the OS — keystroke timings, mouse movements, hardware noise — to seed its output. This matters because predictable randomness in security contexts is functionally no randomness at all; an attacker who knows your PRNG state can reproduce 'random' tokens.

Each character in the output is selected from your chosen alphabet by mapping a random byte to a position in the alphabet. With a 64-character alphabet (URL-safe Base64), each character provides 6 bits of entropy. So a 32-character string has 192 bits of entropy — well past the threshold considered safe for any practical security context. With a smaller alphabet (16-character hex), each character provides 4 bits, so a 32-character hex string is 128 bits — still strong, but using fewer characters per byte of entropy.

A worked example: you need a session token. 32 alphanumeric characters (62-char alphabet) gives roughly 190 bits of entropy. The string `q7kP2mR9xN3vL8sT4hY6jW1cZ5bU0aE` (one such output) is essentially impossible to guess — the search space is 62^32, which is on the order of 10^57. By comparison, 8-character lowercase strings have 26^8 ≈ 200 billion possibilities, which sounds large but can be brute-forced in seconds with modern hardware. Length and alphabet matter together; a long string in a small alphabet is fine, a short string in a large alphabet is not.

When excluded characters matter: for codes that humans transcribe (recovery codes, license keys, gift codes), excluding visually similar characters (0/O, 1/l/I, 5/S) reduces transcription errors. The cost is slightly less entropy per character. For machine-only use (API tokens, session IDs), there's no need to exclude — humans never read them. For mixed cases (printed receipts the user enters into a website), exclusion is worth it; the user error rate matters more than the marginal entropy difference.

What this generator deliberately doesn't do: enforce password complexity rules. A generated password might happen to be all lowercase, or might lack a digit, depending on the configured alphabet. For password generation specifically, the dedicated password generator applies rules like 'at least one digit, one uppercase, one symbol.' This generator is for raw random strings where the alphabet is your only constraint. The two tools serve different purposes; pick the right one for the job.