Random String Generator
Generate cryptographically secure random strings — tokens, API keys, hex values and IDs — right in your browser. Pick a character set (alphanumeric, hex, base64url, digits or your own custom set), set the length (1–256), and generate up to 50 at once with a live entropy read-out. Randomness comes from the browser's CSPRNG (crypto.getRandomValues), never Math.random. Everything runs locally; nothing is uploaded.
Generated entirely in your browser — never sent anywhere. Randomness comes from the browser's cryptographic RNG (crypto.getRandomValues), with rejection sampling so every character is equally likely (no modulo bias). Never Math.random.
What this tool is
- A free, in-browser random string generator for tokens, API keys, secrets and IDs — distinct from a password generator, it is charset-focused and bulk-friendly.
- Choose a character set (alphanumeric, lowercase or uppercase hex, base64url, digits only, or your own custom set), a length from 1 to 256, and generate 1 to 50 strings at once.
- A live entropy read-out shows the exact bits of randomness for your settings (entropy = length × log₂ of the charset size), so you can size a token to a real security target.
- Randomness comes from the browser’s CSPRNG (crypto.getRandomValues) with rejection sampling to remove modulo bias — never Math.random, which is predictable and unsafe for secrets.
- Everything runs client-side. Nothing you generate is ever sent to a server, logged or stored — copy any row or all of them and the values stay on your machine.
What makes a random string secure
A random string is only as trustworthy as the source of its randomness. The strings this tool makes are drawn from a CSPRNG — a cryptographically secure pseudo-random number generator — exposed by the browser as crypto.getRandomValues. It is seeded from the operating system's entropy pool and designed so that seeing earlier output tells an attacker nothing useful about later output. That is exactly what a token, key, salt or secret ID needs.
Why not Math.random
Math.random is a fast, non-cryptographic PRNG. Its state is small and its sequence is predictable: an attacker who observes a handful of its outputs can often reconstruct the generator and predict every value it will produce next. For a shuffle or a jitter that is fine; for anything that acts as a credential it is a vulnerability. This tool therefore uses only crypto.getRandomValues and never falls back to Math.random.
Avoiding modulo bias
Mapping a random number onto a charset of size N with a naive value % N is subtly broken whenever N does not evenly divide the generator's range — the lower symbols come up slightly more often, which leaks entropy. This tool uses rejection sampling: it draws 32-bit values and discards any value at or above the largest multiple of N that fits in 232, so every character is equally likely and the full entropy is preserved.
Entropy, exactly
For a string of length L drawn uniformly from N distinct symbols, the entropy is L × log2(N) bits. So a 32-character hex string is 32 × 4 = 128 bits; a 16-character alphanumeric string is 16 × log2(62) ≈ 95.3 bits; and a 43-character base64url string is 43 × 6 = 258 bits — enough headroom to carry a 256-bit key. The read-out above the output computes this for your exact settings as you change them.
Hex vs base64url vs alphanumeric
- Hex (16 symbols, 4 bits/char). Unambiguous and case-insensitive — ideal for fingerprints, checksums and values copied by hand. Least dense: a 256-bit value needs 64 characters.
- Base64url (64 symbols, 6 bits/char). The most compact text that stays safe in URLs, filenames and headers without escaping. The usual choice for tokens: a 256-bit value fits in 43 characters.
- Alphanumeric (62 symbols, ≈5.95 bits/char). Avoids
-and_, so it is handy when punctuation is treated specially downstream or the value must select cleanly on a double-click. - Digits only (10 symbols, ≈3.32 bits/char). For numeric codes. Note how few bits each digit carries — numeric codes need to be long to be strong.
Handling note: these strings are generated locally and never leave your browser, which makes the tool safe for real secrets — but the value is only as good as how you handle it afterward. Generate on a device you trust, move the result straight into your secret manager or environment config rather than leaving it in your clipboard or browser history, and never generate a production secret in a page you do not trust.
Frequently asked questions
What is a random string generator used for?
A random string generator produces unpredictable sequences of characters for use as API keys, bearer and session tokens, password-reset and invite tokens, CSRF tokens, nonces, salts, database or object IDs, and webhook signing secrets. Unlike a human-readable password generator, it is charset-focused: you pick exactly which characters are allowed (for example hex for a key fingerprint, or base64url for a URL-safe token) and how long the string is, then generate many at once. The security of all of these depends entirely on the randomness being unpredictable, which is why this tool uses a cryptographically secure generator rather than an ordinary one.
Why use crypto.getRandomValues instead of Math.random?
Math.random is a fast, non-cryptographic pseudo-random number generator. Its internal state is small and its output is statistically patterned, so an attacker who sees a few values can often predict the rest — and browsers never promised it was unpredictable. That is fine for shuffling a UI animation and catastrophic for a secret. crypto.getRandomValues is a CSPRNG (cryptographically secure pseudo-random number generator) seeded from the operating system’s entropy pool; its output is designed to be computationally infeasible to predict even with knowledge of previous outputs. Anything that acts as a credential — a token, key, salt or secret ID — must come from a CSPRNG. This tool uses crypto.getRandomValues exclusively and never calls Math.random.
What does the entropy read-out mean and how long should my token be?
Entropy measures how many equally likely values a string could have taken, in bits. For a string drawn uniformly from an alphabet of N distinct symbols, each character contributes log₂(N) bits, so a string of length L has L × log₂(N) bits of entropy. Examples: a 16-character alphanumeric string (N = 62) is about 16 × 5.954 ≈ 95 bits; a 32-character hex string (N = 16) is exactly 32 × 4 = 128 bits; a 43-character base64url string (N = 64) is 43 × 6 = 258 bits, enough to carry a 256-bit key. As a rule of thumb, 128 bits is the common floor for secrets that must resist brute force, and 256 bits is used where a wide safety margin is wanted. The read-out computes this exactly from your current charset and length.
Should I use hex, base64url or alphanumeric?
It depends on where the string goes. Hex (0–9 a–f, 16 symbols, 4 bits per character) is unambiguous, case-insensitive and ideal for fingerprints, checksums and anything copied by hand, but it is the least dense — a 256-bit value needs 64 hex characters. Base64url (A–Z a–z 0–9 and - _, 64 symbols, 6 bits per character) is the most compact text encoding that stays safe inside URLs, filenames and HTTP headers without escaping, so it is the usual choice for tokens — a 256-bit value fits in 43 characters. Alphanumeric (62 symbols, about 5.95 bits per character) avoids the - and _ symbols entirely, which is useful when a downstream system treats punctuation specially or when the value must be selected by a double-click. Digits-only is for numeric codes. Pick the smallest safe alphabet for the destination, then set the length to hit your entropy target.
Are the generated strings sent anywhere? Is it safe for production secrets?
No. Generation happens entirely in your browser using the Web Crypto API; nothing is transmitted to PlayCISO or any third party, and nothing is stored or logged server-side. The strings exist only in the page until you copy them. This makes the tool suitable for generating real secrets — but treat the result like any other credential: generate it on a device you trust, move it straight into your secret manager or environment configuration rather than leaving it in your clipboard or browser history, and never paste a production secret into a page you do not trust. The value of a secret is only as good as how carefully you handle it after it is generated.