"UUID vs ULID vs CUID: Which Unique ID Format Should You Use in 2026?"

Why Unique IDs Are Harder Than They Look

You need a unique identifier for a database row, an API resource, a session token. Easy, right? Just use a number.

The problem with sequential integers: they're predictable (/users/1, /users/2) — anyone can enumerate your resources. They require a central authority to issue (only one server can decide the "next" number). And they leak business information (your 1000th order has ID 1000).

So the world invented better IDs. Then kept inventing more of them. Here's what each actually does.

UUID (v4) — The Safe Default

Format: 550e8400-e29b-41d4-a716-446655440000 Length: 36 characters (32 hex + 4 dashes) Randomness: 122 bits

UUID v4 is 122 random bits formatted in a standard way. The collision probability is so astronomically low (you'd need to generate 1 billion UUIDs per second for 85 years to have a 50% chance of collision) that it's effectively impossible.

What UUID does well:

• Universal standard — every language, database, and framework has native UUID support
• No coordination needed — any server, any client can generate one independently
• Non-sequential — no enumeration attacks

What UUID does badly:

• Not sortable — UUIDs are random, so they don't sort by creation time. In a B-tree index (how most databases work), random insertions cause "page splits" — the database constantly reorganizes its index. At scale, this is expensive.
• Large: 36 chars as a string, 16 bytes as binary
• Not URL-friendly (contains dashes)

Use UUID v4 when: you need a standard, widely-supported ID and don't care about sort order.

UUID v7 — UUID Fixed

Format: 018e2c4c-3d12-7f3a-91f8-3e4a5b6c7d8e Length: 36 characters Randomness: 74 bits (with 48-bit millisecond timestamp prefix)

UUID v7 (ratified in 2023) is UUID with a timestamp prefix. The first 48 bits are a Unix timestamp in milliseconds, making UUIDs sortable by creation time.

Why this matters: sortable IDs = sequential B-tree insertions = dramatically better database index performance at scale.

Use UUID v7 when: you want UUID compatibility but need time-ordered IDs for database performance.

ULID — Sortable, URL-Safe UUID Alternative

Format: 01ARZ3NDEKTSV4RRFFQ69G5FAV Length: 26 characters Randomness: 80 bits (with 48-bit millisecond timestamp prefix)

ULID (Universally Unique Lexicographically Sortable Identifier) solves UUID's sort problem with a cleaner format. It encodes 48 bits of timestamp + 80 bits of randomness in Crockford Base32 (no dashes, no ambiguous characters).

What ULID does well:

• Lexicographically sortable (sorts correctly as a string)
• URL-safe (no dashes or special characters)
• 26 chars vs UUID's 36 chars — more compact
• Millisecond precision timestamp embedded

What ULID does badly:

• Less universal than UUID — library required in most languages
• Monotonicity: multiple ULIDs generated in the same millisecond may not sort correctly without the monotonic variant

Use ULID when: you want sortable IDs that are also compact and URL-safe, and you don't need UUID compatibility.

CUID2 — URL-Safe, Collision-Resistant, No Timestamp

Format: clyg4v5l20000356ok1f5t6nb Length: 24 characters (default) Randomness: high (SHA-3 fingerprinting, no predictable structure)

CUID2 (Collision-Resistant Unique IDentifier) is designed for security-sensitive contexts. Unlike ULID, it deliberately has no timestamp prefix — you can't infer when a resource was created from its ID.

What CUID2 does well:

• More secure than UUID/ULID for public-facing IDs (no timing information)
• URL-safe
• Configurable length (trade-off between length and collision resistance)

What CUID2 does badly:

• Not sortable (by design)
• Less widely supported than UUID
• Depends on a specific library

Use CUID2 when: IDs are public-facing and you don't want to leak creation timestamps (user IDs, API keys, short links).

NanoID — Small, Fast, Customizable

Format: V1StGXR8_Z5jdHi6B-myT Length: 21 characters (default, configurable) Alphabet: customizable (default: URL-safe Base64)

NanoID is a modern, tiny alternative to UUID. Same collision probability as UUID v4 at 21 chars, but smaller and with a customizable alphabet.

What NanoID does well:

• Smallest of the bunch (21 chars vs UUID's 36)
• Customizable alphabet — can generate IDs using only lowercase letters, only numbers, etc.
• Available in 20+ languages
• Fast

What NanoID does badly:

• Not sortable
• Not a standard (no RFC)

Use NanoID when: size matters (URLs, short tokens) or you need a custom alphabet.

Decision Table

The Simple Answer

• Default choice: UUID v7 — sortable, standard, great DB performance
• Need URL-safe + sortable: ULID
• Public IDs (don't leak timing): CUID2
• Short tokens, custom alphabet: NanoID
• Legacy system / maximum compatibility: UUID v4

Generate IDs Now

UUID Generator generates UUID v4 and v7 — bulk generation, one click to copy. No account required.