Random string generator

How to generate random strings

1. Choose a character set. Alphanumeric is the safe default — it survives URLs, filenames, shell arguments and spreadsheets untouched. Pick hex if the value has to sit alongside hashes, base64url if it goes in a URL, digits if it will be read aloud.
2. Set the length. The panel shows the bits per character for the alphabet you chose, so you can work backwards from a target: 128 bits of base64url is 22 characters, 128 bits of hex is 32.
3. Add a prefix or suffix if you want the values to be self-describing. Both are fixed text and add no entropy, which the tool states plainly.
4. Generate in bulk. Up to 500 at a time, copyable as a block or downloadable as a plain text file, one per line.

Bits per character, by alphabet

Entropy is length multiplied by the base-2 logarithm of the alphabet size. This table saves you the arithmetic — the last two columns give the length needed to reach the two thresholds that matter in practice.

What these strings are good for

• API keys and access tokens. 32 base64url characters is 192 bits, comfortably past any brute-force concern. Prefix them (sk_live_, pk_test_) so they are recognisable in logs and so a leaked key can be identified by scanning tools.
• Session identifiers and CSRF tokens. The OWASP guidance is at least 128 bits from a cryptographically secure source, which is what this page produces.
• Database seed data and test fixtures. Bulk mode with a prefix gives you a few hundred unique, obviously-fake values in one click.
• Coupon, invite and licence codes. Use the uppercase alphanumeric set with ambiguous characters excluded so the code can be read over the phone without a spelling alphabet.
• Salts and nonces you are handling by hand. Hex is usually the format the surrounding tooling expects.
• Temporary filenames and cache-busting suffixes. Lowercase alphanumeric avoids every case-sensitivity trap across operating systems.

Why the randomness source matters

A surprising number of "random string" pages are built on Math.random. That function is designed to be fast, not unpredictable: its internal state can be reconstructed from a modest number of consecutive outputs, after which every future value is known. For a dice-rolling animation that is fine. For an API key it is a vulnerability.

This page uses crypto.getRandomValues, which is backed by the operating system's entropy pool — the same source a server-side library would use. It also avoids a subtler problem: converting a 32-bit random number into an index with a plain % makes the first few characters of the alphabet slightly more likely than the rest, because 2³² is not divisible by 62. Draws landing in the final partial bucket are discarded and retaken, so every character is exactly equally likely.

Custom alphabets and duplicate characters

If you supply your own character set, duplicates are collapsed before generation. A character listed twice would otherwise appear twice as often, quietly reducing the real entropy while the figure on the page claimed otherwise. Collapsing them keeps the alphabet size — and the bits-per-character number — truthful.

Choosing a length

For anything that acts as a credential, 128 bits is the standard floor and 256 bits is the belt-and-braces answer. For values that only need to be unique rather than unguessable — a cache key, a filename — 64 bits is already enough that a collision is not going to happen in your lifetime. Where the value will be typed by a human, trade length against the alphabet: uppercase alphanumeric with ambiguous glyphs removed at 12 characters is still 60 bits, and far less error-prone to transcribe than a shorter dense string.