About the Random String Generator
This random string generator creates unpredictable strings for API keys, access tokens, invite codes, test data, session secrets and file names. Choose the length and how many strings you want, then pick a character set — letters and digits, hex, URL-safe Base64, digits only — or build your own from uppercase, lowercase, digits and symbols. Add a prefix such as sk_live_ to mark key types, and remove look-alike characters (0/O, 1/l/I) for codes that people must read or type.
Strings are drawn from your browser’s cryptographically secure random number generator (crypto.getRandomValues) using rejection sampling, so every character in the set is exactly equally likely — no modulo bias. The tool also reports the entropy of each string in bits, so you can check a token is long enough: 128 bits is a common minimum for secrets.
Need repeatable test fixtures instead? Enter a seed and the same seed always produces the same strings (seeded output is predictable and must never be used for real secrets). Nothing is sent to a server.
How to use the random string generator
- 1Set the length and how many strings you need.
- 2Choose a character set, or pick character types or custom characters.
- 3Optionally exclude look-alike characters and add a prefix.
- 4Copy the strings — each new visit or change generates fresh ones.
- 5Enter a seed only when you need the same test data every time.
Formula and method
Each character is chosen independently and uniformly from a set of N characters, so a string of length L can be any of N^L values and carries L × log₂N bits of entropy. A 32-character alphanumeric string (N = 62) has 32 × 5.954 ≈ 190.5 bits; a 64-character hex string (N = 16) has exactly 256 bits.
To pick a character, the generator takes a 32-bit random number from crypto.getRandomValues and keeps it only if it is below the largest multiple of N that fits in 2³²; it then uses the remainder modulo N. Rejecting the few values above that limit removes modulo bias, so no character is more likely than another. A prefix is fixed text and adds no entropy. With a seed, a deterministic sfc32 generator replaces the secure source.
- H
- Entropy per string in bits
- L
- Number of random characters
- N
- Size of the character set
Worked examples
32-character alphanumeric API key
Letters and digits give 26 + 26 + 10 = 62 characters. Each carries log₂62 ≈ 5.954 bits, so 32 characters hold about 190.5 bits — well above the 128-bit minimum for secrets.
256-bit hex secret
Each hex digit encodes exactly 4 bits (log₂16 = 4), so 64 hex digits are a 256-bit secret — the size typically used for HMAC-SHA256 signing keys.
Readable invite codes without look-alikes
Uppercase plus digits is 36 characters; removing 0, O, 1 and I leaves 32. Eight characters give 8 × log₂32 = 40 bits — about 1.1 trillion codes, plenty for invites that are also rate-limited.
Prefixed live key
URL-safe Base64 has 64 characters, 6 bits each, so 24 random characters give 144 bits. The 8-character prefix makes each key 32 characters long but adds no randomness.
Frequently asked questions
Is this random string generator secure enough for API keys?+
Yes, when the seed is blank. It uses the Web Crypto API’s crypto.getRandomValues, a cryptographically secure generator, with rejection sampling to avoid bias. Use at least 128 bits of entropy — for example 22 alphanumeric or 32 hex characters.
How long should a random token be?+
OWASP sets 64 bits of entropy as the floor for session IDs; for long-lived secrets such as API keys, 128 bits is a common target and 256 bits is generous. 128 bits takes 22 alphanumeric characters, 32 hex characters or 22 URL-safe Base64 characters.
What is modulo bias?+
If you map a random byte (0–255) onto 62 characters with % 62, the first 8 characters appear slightly more often because 256 is not a multiple of 62. This generator discards out-of-range samples so every character has exactly the same probability.
Why exclude ambiguous characters?+
In many fonts 0 and O, or 1, l and I look alike, so people mistype codes that they read from paper or a screen. Removing them makes vouchers, invite codes and licence keys easier to enter, at a small cost in entropy per character.
Should I store API keys in plain text?+
Store only a hash of each key (for example SHA-256) on the server and show the full key to the user once. A short, non-secret prefix such as sk_live_ helps identify key types and lets secret scanners detect leaked keys.