Nano ID Generator

A default Nano ID is 21 characters from a 64-symbol alphabet, giving 126 bits of entropy - slightly more than a version 4 UUID's 122, in 21 characters instead of 36. The saving comes from the encoding rather than from any compromise in randomness. A UUID writes 128 bits as hexadecimal, which packs only 4 bits per character, and then adds four hyphens. Nano ID uses a 64-symbol alphabet at 6 bits per character and no separators.

Where that matters is anywhere identifiers are visible or repeated. A 40% shorter identifier makes URLs more manageable, fits more comfortably in fixed-width UI, and reduces bytes across every index and log line at scale. For an identifier a user might read aloud or type, the difference is more than cosmetic.

The default alphabet is `A-Za-z0-9_-`, chosen to be URL-safe without percent-encoding. Both `_` and `-` are unreserved in RFC 3986, so an ID can sit in a path or a query string untouched.

The variant worth knowing about is the no-look-alikes alphabet, which removes characters that are easily confused - `0` and `O`, `1`, `l` and `I` - and also strips vowels to avoid generating real words, which matters more than people expect for user-facing codes. Use it for anything a human will read from a screen, copy from a printed page, or dictate over the phone. The cost is fewer symbols per character, so you need a longer ID for the same entropy.

Numbers-only alphabets are sometimes requested for legacy systems that cannot store letters. They work, but the entropy per character drops to about 3.3 bits, so a numeric ID needs roughly twice the length of the default to be equally safe. Check the length rather than assuming the default is still adequate.

The right length depends on how many identifiers you will generate and how badly a collision would hurt. At 21 characters with the default alphabet, you would need to generate a billion IDs per second for about 1,700 years to reach a 1% collision probability - comfortably beyond any application's needs.

Shortening is reasonable when volumes are small and a collision is recoverable. Ten characters gives 60 bits, which is fine for a few million records where the database has a unique constraint to catch the rare duplicate. Going below eight is where it gets risky, and the failure is silent unless you have that constraint.

The rule worth following is to keep a unique index on the column regardless of length. It costs nothing and turns an unlikely, hard-to-diagnose data corruption into an ordinary insert error that you can retry.