Skip to content
ZeroServer.tools
All guides

UUID vs ULID vs Nano ID: Choosing an ID Format

June 4, 2026 · 4 min read

Every app needs unique identifiers — for database rows, public URLs, API objects, file names. The default reflex is "generate a UUID," but UUID isn't always the best fit, and two newer formats — ULID and Nano ID — solve real problems that classic UUIDs don't. This guide compares all three on the things that actually matter: collision-resistance, sortability, length, URL-friendliness, and how kindly they treat your database indexes.

UUID v4: the ubiquitous default

A UUID is a 128-bit identifier, and v4 is the random variant almost everyone means by "UUID." It's rendered as 36 characters — 32 hex digits plus four hyphens:

f47ac10b-58cc-4372-a567-0e02b2c3d479

UUID v4 is random, which gives it excellent collision-resistance: with 122 bits of randomness, you can generate enormous numbers of them without a realistic collision. It's supported everywhere, in every language and database. Its main drawbacks are that it's not sortable (two UUIDs generated a second apart have no order relationship), it's relatively long, and the hyphens plus hex make it neither compact nor especially URL-pretty.

ULID: sortable by time

A ULID is also 128 bits, but it's built differently. The first 48 bits are a millisecond timestamp and the remaining 80 bits are random. It's encoded in Crockford base32 as 26 characters with no hyphens:

01ARZ3NDEKTSV4RRFFQ69G5FAV

The clever part: because the timestamp comes first and base32 preserves byte order, ULIDs are lexicographically time-sortable — sort them as plain strings and you get chronological order. They're URL-safe (Crockford base32 avoids ambiguous characters like I, L, O, and U), shorter than a UUID, and still carry 80 bits of randomness so collisions within the same millisecond remain very unlikely.

Nano ID: compact and tunable

Nano ID takes a different angle. It's a short, random string from a URL-safe alphabet (A–Z, a–z, 0–9, plus _ and -), and the length is configurable — the default is 21 characters:

V1StGXR8_Z5jdHi6B-myT

By dropping the fixed 128-bit structure, Nano ID lets you trade length for collision space explicitly. A 21-character Nano ID has collision-resistance comparable to UUID v4, while a shorter one is more compact for public-facing IDs where you accept a smaller (but quantifiable) collision probability. It's not sortable — it's purely random — but it's the friendliest of the three for short links and visible identifiers.

How they compare

  • Randomness / collision-resistance — UUID v4 has 122 random bits; ULID has 80; Nano ID is tunable (its default ~126 bits of entropy rivals UUID). All three are safe for high-volume generation at their default sizes.
  • Sortability — Only ULID is time-sortable out of the box. UUID v4 and Nano ID are not. (If you need sortable UUIDs specifically, UUID v7 exists and is time-ordered like ULID.)
  • Length — Nano ID (21, adjustable) is shortest by default, ULID is 26, UUID is 36. Fewer characters means smaller payloads and tidier URLs.
  • URL-friendliness — ULID and Nano ID are designed to be URL-safe with no encoding. UUID's hyphens are legal but uglier in a path.

Database index performance

This is where the choice has real cost. Most databases store primary keys in a B-tree index. When keys arrive in random order — as with UUID v4 — each insert lands at an arbitrary spot in the tree, scattering writes across many pages, causing page splits, and fragmenting the index. On a large, write-heavy table this hurts insert throughput and bloats the index.

Time-ordered keys behave much better. Because ULIDs (and UUID v7) are roughly monotonic — each new value sorts after the last — inserts mostly append to the "right" edge of the tree. That packs pages densely, reduces fragmentation, and keeps recent rows physically close, which also helps range scans over recent data. This is the single strongest reason to prefer ULID over UUID v4 for a primary key.

Which should you pick?

  • Database primary keys — prefer a time-sortable ID: ULID (or UUID v7 if you want to stay within the UUID standard). You get sequential inserts and better index locality. Plain UUID v4 works but pays the fragmentation tax.
  • Public-facing object IDs — ULID or Nano ID. They're URL-safe and shorter, and ULID adds a free creation-time signal.
  • Short links and visible codes — Nano ID, sized to your tolerance for length vs. collision space.
  • Maximum interoperability / existing systems — UUID v4 remains the safe lingua franca.

It runs in your browser

All three generators here run entirely in your browser — IDs are produced by JavaScript on your machine using a cryptographically strong random source, with nothing sent to a server. Use the UUID Generator, the ULID Generator, or the Nano ID Generator.

Try it

Generate identifiers with the free UUID Generator — no signup, nothing leaves your browser. Need time-sortable keys or compact public IDs? Try the ULID Generator and the Nano ID Generator.