How does a NanoID differ from a UUID?
In its written form and its alphabet. A UUID is 36 characters with dashes and a fixed internal layout: it carries version and variant fields, so part of its bits is spent on those rather than on randomness. A NanoID is simply a string of characters drawn from the chosen alphabet, with no service fields at all. At the default length of 21 characters over a 64-character alphabet that is 126 bits of randomness — practically as much as a version 4 UUID, in a form 15 characters shorter.
What NanoID length should I use?
21 characters is the usual choice: it keeps a collision improbable at any reasonable volume. Each character of a 64-character alphabet adds 6 bits, so the length can be tuned to the task: 10 characters give 60 bits and suit short links, 32 characters give 192 bits for long-lived keys. When shortening, keep in mind that the collision probability grows with the square of the number of identifiers issued, not linearly.
Can a NanoID go into a page address?
Yes, that is exactly what the default alphabet is picked for: it holds only Latin letters, digits, a dash and an underscore — characters that need no escaping in an address, a file name or an HTML element id. If the identifier will be read out loud or typed by hand, take the alphabet without capitals: it is 26 characters smaller, but it also causes less confusion.
Does a NanoID sort by creation time?
No, it holds no timestamp — every character is random. If you need an identifier whose string order matches the order of creation, take a ULID or a version 7 UUID. The flip side of that ordering is that the identifier reveals when a row was created and roughly how many have been issued — a NanoID leaks nothing.