UUID vs NanoID

NanoID is shorter and carries more entropy. That sounds like it should settle the question, so start by looking at how small the difference actually is.

By the Withuse team · Updated September 7, 2026

Run the numbers first

# alphabet size ^ length, versus 2 ^ random bits
64 ** 21     # NanoID  →  8.51e+37   (126 bits, 21 chars)
2 ** 122     # UUID v4 →  5.32e+36   (122 bits, 36 chars)

ratio        →  16.0x more possible values
length       →  21 chars vs 36  (58%)

Sixteen times more headroom, and it buys nothing you will ever observe. The collision arithmetic puts a 50% chance at roughly 2.7 × 10¹⁸ UUIDs — about 86 years of generating a billion per second, continuously. Multiplying an already unreachable number by sixteen does not change any decision you will make.

The length difference is the real one. Twenty-one characters against thirty-six is visible in a URL somebody copies, reads aloud, or types from a screenshot.

Where the fifteen characters go

A UUID spends 4 bits per hexadecimal character and adds four hyphens for readability. NanoID uses a 64-symbol alphabet — A-Za-z0-9_- — so each character carries 6 bits, and it adds no separators at all. That accounts for most of the gap before entropy enters into it.

The rest is structure. A UUID gives up six of its bits to version and variant markers, which is exactly what lets a decoder tell you how a value was produced and when. Nothing can inspect a NanoID and say anything about it at all. The compactness and the opacity are not two features — they are one decision, and which side you want depends on whether anything downstream needs to read the value rather than merely store it.

Side by side

The trade is tooling, not entropy

UUID is a specification with an ecosystem grown around it: a native uuid column type in PostgreSQL, a BSON subtype in MongoDB, a Guid struct in .NET, a standard-library module in Python, a decoder in every language anyone has written one for.

NanoID is a well-regarded library with ports to many languages, but a convention is not a specification. A NanoID is a plain string everywhere — no column type, no built-in validation, nothing that recognises the shape. In PostgreSQL that means text where a UUID would occupy 16 bytes in a purpose-built type, and you pay that difference on every index entry rather than once per row. On a large table that is a real cost, and it is invisible until the index stops fitting in memory.

No NanoID equivalent of v7

NanoID is entirely random, so as a primary key it behaves like v4: inserts scatter across the index instead of appending at the end, causing page splits and a working set that outgrows memory sooner than the row count suggests. There is no timestamp-prefixed variant and no plan for one.

If insert locality matters — and in any table taking real write volume it does — v7 is the option that has it. The full argument is in v4 vs v7.

Choosing

Use NanoID when the identifier appears in a URL people see and the storage is a string either way. Its configurable length is a genuine advantage there: you can shorten it, or drop look-alike characters from the alphabet, and compute exactly what entropy remains rather than guessing.

Use UUID when the value crosses a system boundary, lands in a typed column, or benefits from being recognisable as a UUID to whatever reads it next. Neither is a credential — see is a UUID secure before either one ends up in a password reset link.

Short answers

Generate UUIDs with the free generator, or read one with the decoder. Related: UUID vs ULID · UUID vs ObjectId