UUID generator · formatNanoID — a short identifier
NanoID is 21 characters from a 64-character alphabet of A–Z, a–z, 0–9, “_” and “-”: 126 random bits — slightly more than UUID v4's 122 — yet 15 characters shorter and needing no URL encoding. Length and alphabet are adjustable, and they decide how many values you can issue before collisions become a risk.
An ID in a page address: short links, document IDs, invites.
Codes people read — with the alphabet that drops look-alike characters.
Not for a database sorted by time: there is no time inside and the order is random.
How it differs from its neighbours
Against UUID v4: as much randomness or more in 21 characters instead of 36, with no hyphens, but NanoID is a library rather than a standard, and a database uuid column will not accept it. Against ULID: ULID sorts by time, NanoID does not. Shortening NanoID shrinks the margin: 10 characters is 60 bits, and collisions become real at billions of values.
In length and status. By default a NanoID is 21 characters without hyphens from a URL-safe alphabet, with 126 random bits; a UUID v4 is 36 characters and 122 bits. But UUID is an RFC standard with a database type and functions in every language, while NanoID is a library. NanoID suits links and screens, UUID suits schemas and protocols.
It depends on how many values you will issue. By the calculator in the NanoID docs, at length 21 and a thousand values an hour it takes about 149 billion years to reach a 1% chance of a collision. Ten characters give 60 bits, and collisions become real at billions of values. Go below 12–14 characters only when values are certain to be few.
So the alphabet has exactly 64 characters, each carrying six bits, and the value needs no encoding in a page address. They are the same characters as in the URL-safe variant of Base64. If “_” and “-” get in the way — when selecting by double click or in file names — pick the letters-and-digits alphabet; the length grows by a bit or two.
No. A uuid column accepts only 32 hexadecimal digits, and a NanoID is a string of a different alphabet and length. Store it in a fixed-length text column such as char(21) with a unique index. If the database is already built on UUIDs, keep the UUID as the key and use NanoID alongside it as a short public identifier.
Choose the alphabet without look-alikes: it drops 0 and O, 1, l and I, which get confused when read or typed by hand. Each character then carries slightly fewer bits, so add a character or two to keep the same margin. The library itself offers customAlphabet, a function you pass your own character set to.
At full length with a cryptographic generator, yes: 126 random bits cannot be brute-forced, and here characters are chosen by rejection from crypto.getRandomValues with no bias toward the start of the alphabet. The danger is shortening: six to eight characters can be enumerated in reasonable time. For private links keep the length at 21 or more.