Nano ID Generator

What this tool does

This tool generates Nano IDs in your browser using the algorithm documented in the nanoid README: short, URL-safe, random strings such as 0vWs6pBE-3Q8WdkFjNvd1. You choose the length (1 to 256), the alphabet and how many to produce (up to 50). Next to the IDs it reports the entropy in bits and a collision estimate for your exact settings.

When you need it

• You want shorter IDs than a UUID for URLs, share links, invite codes or database keys.
• You need IDs that use only characters you allow, such as digits, lowercase letters, or a set without look-alike characters.
• You are deciding how long an ID has to be and want to see the collision risk before committing.
• You are producing sample data compatible with what the nanoid library generates.

The algorithm

The default is 21 characters from a 64-symbol alphabet (A-Z, a-z, 0-9, _ and -, in the library's shuffled order). That gives 21 × 6 = 126 bits of randomness, slightly more than the 122 in a UUID v4, in 21 characters instead of 36.

For a custom alphabet the README describes a rejection-sampling method, and this tool implements it directly. It computes a bit mask, the smallest 2^k − 1 that covers the alphabet. It then requests random bytes, ANDs each byte with the mask and keeps the result only if it points inside the alphabet. A larger step is requested up front (about 1.6 times the bytes needed) so one batch of randomness usually finishes the ID. Discarding out-of-range values is what keeps every character equally likely. The shortcut of byte % alphabet.length would favor the first characters whenever the alphabet size does not divide 256, which is the bias this approach avoids.

Random bytes come from crypto.getRandomValues, the browser's secure generator.

Reading the collision figure

The page shows how many IDs you would generate before there is a 1% chance that at least one pair matches. This is the birthday problem: with N = alphabet^size possible IDs, the count is approximately sqrt(2 × N × ln(1 / (1 − 0.01))). The time shown divides that count by the IDs-per-hour rate you enter. At 1,000 IDs per hour, the default settings come out near 149 billion years, which matches the figure quoted in the nanoid README. When the whole ID space is under a billion values, the page switches to an exact calculation instead of the approximation, because the approximation is poor for tiny spaces.

Two practical lessons come out of experimenting with the numbers. First, length matters more than alphabet size: each extra character multiplies the space by the alphabet size, while a bigger alphabet only raises the base. Second, short numeric IDs are fragile. Eight digits give about 26.6 bits, and the page shows a 1% collision chance after only 1,419 IDs. If you need short IDs, check them against the ID count you expect, and enforce uniqueness in the database anyway.

Custom alphabet rules

The alphabet must have at least 2 and at most 255 distinct characters, matching the constraint that the algorithm works on single random bytes. Repeated characters are rejected rather than silently collapsed, because a repeat would make that character more likely and make the entropy figure wrong. Remove characters like 0, O, 1, l and I when people will read the ID aloud or retype it.

Limits and honesty

An ID is an identifier, not a secret. For access tokens, use enough length and treat the value like a password. IDs from this page are unlikely to repeat, but randomness cannot replace a unique constraint when correctness depends on it. Because output is random, the examples on this page show settings, not fixed results.