Use the free NanoID Generator below: your data never leaves your browser — all work happens on your device, and nothing is uploaded to any server.
NanoID: the tiny ID that replaced UUIDs in many apps
NanoID is a small library for generating unique IDs, created as a compact alternative to UUIDs. A default NanoID is 21 characters long and looks like “V1StGXR8_Z5jdHi6B-myT”. It uses a URL-safe alphabet of 64 characters: uppercase and lowercase letters, digits, dash and underscore. Because the alphabet is larger than hex, 21 characters carry about 126 bits of randomness, roughly the same as a UUID, in a string 15 characters shorter. That compactness is why NanoIDs show up in URLs, file names and short codes everywhere.
The design is deliberately minimal. There is no timestamp, no version digit, no structure at all: just random characters from an alphabet. That simplicity is the point. NanoID does one job, generating random IDs, and it does it with a small amount of code and a fast algorithm. It became popular in the JavaScript ecosystem, where its tiny size mattered for web bundles, and it has since been ported to many other languages.
Size, alphabet and the collision math
The safety of a random ID depends on two numbers: how many characters it has, and how many characters the alphabet contains. Multiply the length by the logarithm of the alphabet size and you get the entropy in bits. A 21-character ID from a 64-character alphabet has about 126 bits. A 10-character ID from digits alone has about 33 bits, which is far too small for anything public, because collisions become likely after tens of thousands of IDs. This tool shows the entropy for every ID it generates, so you can see the trade-off instead of guessing.
The birthday paradox governs collisions: with N possible IDs, collisions become likely after roughly the square root of N IDs. For 126 bits, that is around 2 to the power of 63 IDs, a number no real system reaches. For 33 bits, it is around 100,000 IDs, which a busy system can reach quickly. The lesson is simple: for anything exposed to the public or stored long-term, use at least 21 characters from the full alphabet. Shorter IDs are fine for temporary, low-volume uses, but not for permanent public identifiers.
Choosing an alphabet
The default URL-safe alphabet is the best general choice. It works in URLs, file names and most databases without escaping. The digits-only alphabet is useful when humans must type the ID, for example a short code read over the phone, but it needs a longer ID to reach the same entropy. Lowercase-only is useful when a system forces lowercase. Hex is useful when you need compatibility with tools that expect hex strings. Whatever you choose, keep the length generous: a longer ID costs almost nothing and buys a large safety margin.
One subtle point: generating IDs with modulo bias can make some characters slightly more likely than others. A careful implementation uses rejection sampling, discarding random bytes that would skew the distribution, and this tool does exactly that. The difference is tiny for large alphabets, but correctness here costs nothing, so there is no reason to skip it.
Where NanoIDs work best
NanoIDs are ideal for public-facing short identifiers: comment IDs, upload file names, share links, invitation codes and temporary tokens. They are also good as database keys in systems that accept string keys. They are not a good choice when you need sortability, because random IDs scatter through an index; for that, use ULIDs. They are not secret tokens either: a NanoID is unpredictable, but it should not be the only protection on sensitive data, and it should be combined with proper authentication.
If you are migrating from UUIDs, the practical difference is mostly cosmetic: shorter strings, no hyphens, no version digits. The uniqueness guarantees are comparable at the default size. The main thing to check is whether your storage and tooling accept the alphabet you choose, especially the dash and underscore in the default set.
Common questions
Is NanoID better than UUID? For compactness and URL-friendliness, yes. For standardization and tooling, UUID still wins. How long should my IDs be? Twenty-one characters from the default alphabet is the standard and is safe for nearly every use. Are these IDs generated locally? Yes. This tool uses your browser’s cryptographic random generator, and nothing is sent to any server.