UUID vs NanoID

Anatomy: what is inside each ID

UUIDs encode their own metadata. Bits 48–51 hold the version — 1 for time-plus-MAC, 4 for random, 7 for time-ordered random — and two more bits fix the variant. A v4 always looks random; a v7 starts with a readable timestamp, because its first 48 bits are milliseconds since the Unix epoch and UUIDs minted on the same day share a prefix.

NanoIDs carry no metadata. Each character is an independent draw from the alphabet, chosen with masking and rejection sampling over crypto.getRandomValues so every symbol stays uniformly likely. That purity is why the format flexes — change the alphabet or length, keep the algorithm — and why a NanoID reveals nothing about when it was made.

Collision maths: why neither one ever collides

The birthday bound says an n-bit random identifier reaches a 50 percent collision probability near 2^(n/2) draws. For UUID v4 that is roughly 2^61 — about 2.3 quintillion IDs — before a single duplicate's odds reach half; NanoID's 126 bits push the bar slightly further. In practice both are never-happens systems — any duplicate you meet is a code bug, not an entropy event.

This equivalence is why the size debate matters less than assumed: 21 NanoID characters are not safer than a v4 UUID — the same guarantee in fewer bytes. The honest reasons to choose are operational fit — storage, URLs, tooling — not collision risk.

Databases: the index-locality problem

Insert a random key into a B-tree index and the row can land on any page; fill pages partway in random order and every insert risks a page split, extra writes and a colder cache. That is the fragmentation tax both UUID v4 and NanoID pay — NanoID included, because it is just as random. On an indexed primary key at write-heavy scale, neither is index-friendly by default.

UUID v7 is the fix that ships inside the standard: its leading 48 bits are a millisecond timestamp, so new keys nearly always sort to the right edge of the index. NanoID cannot offer this: no time component, nothing to sort by. In an indexed column the real choice is v7 versus everything else.

• v4 and NanoID scatter inserts across the tree — page splits and cache misses at scale.
• Postgres' uuid type stores 16 raw bytes; a 36-character text key stores 37 or more.
• NanoID's text edge — 21 characters against 36 — holds only while the alphabet stays documented.

URLs, alphabets and the length dial

NanoID's alphabet is URL-safe by construction: A-Za-z0-9_- need no percent-encoding anywhere in a URL, so an ID can be a path segment, query value or slug with zero escaping. UUIDs are technically URL-safe too — hex digits and hyphens never need encoding — but 36 characters is a lot of visible string for a link.

The custom alphabet is NanoID's most practical feature: numeric-only codes, lowercase short links — swap the 64 symbols, keep the algorithm. Respect the rule that entropy is length times log2 of alphabet size: an 8-character lowercase NanoID is about 38 bits, fine for a one-hour code, reckless as a primary key. UUIDs offer no such dial; the format is fixed at 128 bits.

When to pick which

Pick UUIDs when the ID lives in infrastructure: database primary keys (v7), interchange between teams and vendors, anything a third party must validate, anywhere a built-in beats a dependency. The standard is the product — every language, ORM and database already speaks it.

Pick NanoID when the ID is user-visible: short URLs, invitation links, file names, cookie values, request IDs in logs. The guidance reverses cleanly — if you keep fighting a UUID's width inside a URL, that link wants NanoID; if you find yourself reimplementing NanoID in a backend whose database could serve keys natively, that column wants a v7 UUID.