Length, Alphabets, and How Much Entropy You Need

Entropy is bits, not characters. A 21-character Nano ID on the default 64-character alphabet carries 126 bits, slightly more than a UUID v4's 122, in 15 fewer characters. The alphabet decides what each character is worth, and shortening an ID moves the collision math faster than most people expect.

Generate a Nano ID at its default settings and you already beat a UUID v4 on entropy per character. Reach for a longer or denser alphabet once you know how many IDs you'll actually mint; reach for something shorter only after you've run the numbers in the sections below, not before.

How many bits does one character carry?

One character is worth log2(alphabet size) bits, because that's how many bits it takes to represent a single draw from that alphabet.

Total entropy is just length times bits per character: entropy = length * log2(alphabet size). A UUID v4's 36-character text form spends most of its width on hyphens and a fixed version nibble, and still lands at 122 bits, because hex is worth only 4 bits a character. A 21-character Nano ID on the 64-character default alphabet reaches 126 bits in 15 fewer characters, because each of its characters is worth 6 bits against hex's 4.

Try your own alphabet and length below. The comparison table under it pulls every format's entropy straight from the registry this site's decoder pages read from.

How do you turn a length into a collision probability?

The birthday approximation converts a keyspace and a target probability into the count of IDs it takes to reach that probability: n ≈ sqrt(2 * N * ln(1 / (1 - p))), where N is the keyspace.

Work it for UUID v4 at even odds, p = 0.5, on one collision anywhere in the whole space.

1. Keyspace: N = 2^122, from the 122 bits above.
2. Probability term: ln(1 / (1 - 0.5)) is ln(2), about 0.6931.
3. Plug in: n ≈ sqrt(2 × 2^122 × 0.6931), which is sqrt(2^123 × 0.6931).
4. sqrt(2^122) is exactly 2^61, about 2.306 × 10^18. Pulling that out leaves a multiplier of sqrt(2 × 0.6931), about 1.1774.
5. n ≈ 1.1774 × 2.306 × 10^18 ≈ 2.71 × 10^18, or 2.71 quintillion UUID v4s.

Mint them at a billion a second, the calculator's own default, and 2.71 × 10^18 IDs takes about 86 years of continuous generation for even odds on one collision. Nothing about that derivation is specific to UUID v4. Swap in any format's bit count, or your own alphabet and length from the calculator above, and the same five steps apply.

What does each ID format actually carry?

Six formats on this site carry very different amounts of randomness for very different character counts, and every figure below comes from the format's own spec.

UUID v4 carries 122 bits, not 128. RFC 9562 §5.4 lays out the field: 48 random bits, a 4-bit version fixed to 0100, 12 more random bits, a 2-bit variant fixed to 10, then 62 more random bits, for 122 random bits total. The RFC says as much directly: an implementation may generate exactly those 122 random bits and concatenate the version and variant into their fixed positions afterward. Most competing pages still say 128.

Cuid2 is the honest gap in this table. Its 24-character default draws from a 36-character alphabet with a constrained first character, which gives it a combinatorial ceiling around 123 bits. paralleldrive/cuid2 never states how much of that ceiling its underlying hash actually fills, and we won't invent a number to fill the cell. Treat Cuid2 as collision-resistant by design, not as a stated bit count you can budget against.

How do you choose a length from a risk budget?

Pick your risk budget first and solve backward for the length, rather than picking a length and hoping.

1. Decide how many IDs you will ever mint, n.
2. Decide the collision probability you can tolerate, p.
3. Solve the birthday formula for bits: N = n^2 / (2 * ln(1 / (1 - p))), then bits = log2(N).
4. Divide by your alphabet's bits per character and round up.

Notice the alphabet barely matters once you're past hex. Base62 and base64url differ by less than half a bit per character, so at these lengths they round to the same character count. The alphabet matters far more at the short end, which is where the next section lives.

Where do short IDs actually bite?

Short IDs bite at the low end of the birthday curve, sooner than intuition suggests, and in ways a character-count comparison hides.

Take a 6-character ID from a 36-character alphabet, the kind of thing a short-URL slug or an invite code often uses. That's 6 * log2(36), about 31 bits, a keyspace of 36^6, or 2,176,782,336 combinations, 2.18 billion. Run the same birthday formula and a 1% chance of one collision arrives after just 6,615 IDs. Even odds arrive by around 54,930. A service minting a few thousand invite codes a day gets there in weeks, not years.

Three things make short IDs riskier than the entropy number alone suggests:

Humans type them. A short ID that mixes 0 and O, or 1, l, and I, generates support tickets before it generates collisions. The alphabet options in the calculator above include a look-alike-free set for exactly this reason.

Short IDs get enumerated. A 6-character space an attacker can walk in full is not really 31 bits of protection against guessing, only against accidental collision. If the ID also has to resist guessing, budget bits for that separately.

The curve is a square root, not a percentage. Halving the bit count doesn't halve your safety margin, it takes the square root of the count of IDs it takes to reach even odds. A 36-bit ID reaches even odds at around 308,650 IDs; halve it to 18 bits and even odds arrive at around 603, about 500 times sooner for half the bits.

Common questions

Does a longer ID always mean more entropy?

No. Length only helps if the alphabet stays fixed. A 26-character ULID and a 27-character KSUID both beat a 21-character Nano ID on raw length, and the Nano ID still edges out the ULID because 6 bits a character beats 5.

Is Cuid2's entropy documented anywhere?

Not as a bit count. paralleldrive/cuid2 documents the algorithm, a 24-character default over a 36-character alphabet, but never states how much of the resulting hash is unpredictable. The registry this site draws from records that field as null rather than guessing.

Should I strip look-alike characters from my alphabet?

For anything a person will type or read aloud, yes. Dropping 0, O, 1, l, and I costs you roughly half a bit per character against base62, which the risk-budget method above will happily tell you to make up with one or two extra characters.

Every generator on this site, including Nano ID and UUID v4, runs entirely in your browser: nothing you generate is sent anywhere. Pick your alphabet and length from the risk budget above, then go generate.