Random String Generator

How it works

• Characters are drawn from your chosen set using the browser’s cryptographic random number generator, with rejection sampling so the distribution stays uniform — a plain modulo would make the first few characters of the set slightly more likely.
• The pattern field builds structured codes: A is an uppercase letter, a is lowercase, 9 is a digit, # is a letter or digit, * is any character including symbols, and anything else is a literal. Use a backslash to escape.
• Excluding lookalike characters removes 0/O, 1/l/I, 5/S, 8/B and 2/Z, which is what you want for anything a human will read aloud or retype from a printed card.
• The entropy readout shows how many bits of randomness each string actually carries, so you can judge whether the length you picked is enough for the number of codes you plan to issue.

Use cases

Designing a code people will type correctly

If a code will ever be read off a screen, a printed card, or a photograph, the character set matters more than the length. The reliable confusions are 0 against O, 1 against l and I, 5 against S, 8 against B, and 2 against Z. In a sans-serif font some of these are genuinely indistinguishable, and support tickets about "invalid code" are usually one of them. Excluding the lookalikes costs you a little entropy and removes an entire category of failure.

Shape helps as much as character set. A code grouped as AAAA-9999 is easier to read back than eight unbroken characters, because people chunk short groups naturally and lose their place in long ones. The pattern field exists for this: A for an uppercase letter, a for lowercase, 9 for a digit, # for either, * for anything, and literal characters anywhere you want them. A hyphen costs nothing and measurably reduces transcription errors.

Case is the last decision. Uppercase-only codes are easier to read aloud and avoid the question of whether redemption should be case-sensitive — and if you are generating codes for humans, redemption should not be case-sensitive, because nobody will remember which it was.

How much entropy is enough

Entropy measures how many equally likely possibilities a string is drawn from, in bits. Each bit doubles the space, so 40 bits is about a trillion possibilities and 60 bits about a quintillion. The number you need depends on which problem you are solving, and they have very different answers.

For collisions, the rule of thumb is to keep the space at least a million times larger than the number of codes you will ever issue. Ten million codes therefore wants a space of around 10^13, which eight characters of uppercase letters and digits comfortably exceeds. For guessing, the bar is much higher, because an attacker can try: if someone gains something by finding a valid code, assume they will make millions of attempts, and either go above 60 bits or put rate limiting in front of redemption. Rate limiting is usually the better answer, since it also protects you from the codes you issued last year at a shorter length.

This matters because the two failures look different in production. A collision shows up as a confusing duplicate; a guessable code shows up as an unexplained spike in redemptions. The entropy readout above tells you which risk you are carrying.

Where random strings are the wrong answer

Random strings are the right tool for identifiers, codes, and test data. They are the wrong tool in three cases worth naming, because each has a better alternative that is easy to reach for once you know it.

For anything that needs to be verifiable later without a database lookup, use a checksum or a signature rather than pure randomness. A coupon code that can be validated offline, or an account number that should reject a typo rather than silently matching another record, wants a check digit. Pure random strings give you no way to tell a typo from a wrong code.

For anything that must be unique across systems that cannot coordinate, use a UUID. A random string is unique only within the batch it was generated in; nothing stops two separate runs colliding. And for secrets, use the tooling built for secrets: a password manager for passwords, and the issuing service for API keys and tokens, which should generate them where they will be verified rather than in a browser tab.

FAQ