UUID vs Nano ID vs CUID: Choosing the Right ID Format

Every application needs unique identifiers. Database primary keys, session tokens, file names, API request IDs, and URL slugs all require strings that won't collide with each other. But the ecosystem of ID formats has grown, and choosing the right one involves tradeoffs around length, sortability, performance, and collision resistance. This guide compares the most popular formats and helps you pick the right one for your use case.

UUID v4: The Universal Standard

UUIDs (Universally Unique Identifiers) are the most widely supported ID format across languages, databases, and protocols. UUID v4, the most common version, generates 122 bits of randomness encoded as 32 hex characters with 4 hyphens.

// UUID v4 format
550e8400-e29b-41d4-a716-446655440000

// Structure: 8-4-4-4-12 hex characters
// Total length: 36 characters (with hyphens)
// Unique bits: 122 (6 bits reserved for version/variant)

// JavaScript
crypto.randomUUID()

// Python
import uuid
str(uuid.uuid4())

// Command line
uuidgen

UUID v7: The Sortable Evolution

UUID v7 is a newer standard (RFC 9562) that embeds a Unix timestamp in the first 48 bits. This makes v7 UUIDs sortable by creation time while still providing 74 bits of randomness. If you need database-friendly UUIDs that sort chronologically, v7 is the modern choice.

// UUID v7 format (time-sortable)
018f3e5c-9a1b-7d4e-8f2a-3b5c7d9e1f0a
│              │
└── timestamp ─┘ └── random ──────────┘

// UUIDs generated later will sort after earlier ones
// Great for database primary keys (reduces index fragmentation)

Generate UUIDs in any version with the UUID Generator.

Nano ID: Compact and URL-Safe

Nano ID was designed as a smaller, URL-safe alternative to UUIDs. Instead of hex characters, it uses a larger alphabet (A-Z, a-z, 0-9, _ and -) which packs more entropy into fewer characters.

// Nano ID format (default 21 characters)
V1StGXR8_Z5jdHi6B-myT

// Alphabet: A-Za-z0-9_-  (64 characters)
// Default length: 21 characters
// Entropy: 126 bits (comparable to UUID v4's 122 bits)

// JavaScript
import { nanoid } from 'nanoid'
nanoid()     // "V1StGXR8_Z5jdHi6B-myT"
nanoid(10)   // "IRFa-VaY2b"  (custom length)

// Custom alphabet
import { customAlphabet } from 'nanoid'
const nanoid = customAlphabet('0123456789abcdef', 12)
nanoid()     // "4f90d13a42de"

Why Nano ID over UUID?

• 40% shorter: 21 characters vs. 36. This adds up in URLs, logs, and storage.
• URL-safe by default: No special characters that need encoding. UUIDs are technically URL-safe too, but Nano IDs are also nicer in filenames and CSS classes.
• Customizable: You can choose the alphabet and length. Need short IDs for user-facing URLs? Use 10 characters. Need maximum collision resistance? Use 36.
• No hyphens: Easier to double-click and select the full ID in text editors and terminals.

Try generating Nano IDs with different lengths using the Nano ID Generator.

CUID2: Secure and Sortable

CUID2 is the successor to CUID, designed specifically for horizontal scaling and security. It produces collision-resistant IDs that are sortable and safe to expose in URLs, without leaking timing information or machine identity.

// CUID2 format (default 24 characters)
clh3am8p10000qwer1234abcd

// Properties:
// - Starts with a letter (valid as HTML id, CSS selector)
// - Default 24 characters, configurable
// - Monotonically sortable within a single host
// - No information leakage (unlike CUID v1)
// - Uses SHA3-based hashing internally

// JavaScript
import { createId } from '@paralleldrive/cuid2'
createId()   // "clh3am8p10000qwer1234abcd"

// With custom length
import { init } from '@paralleldrive/cuid2'
const createId = init({ length: 32 })

Comparison Table

Collision Probability

How worried should you be about two IDs being the same? For properly implemented random generators, the probability is astronomically low, but the numbers are worth knowing.

UUID v4 (122 bits of entropy):
  - Need to generate 2.71 × 10^18 IDs for a 50% chance of collision
  - At 1 billion IDs per second, that takes 86 years
  - For practical purposes: collisions will not happen

Nano ID (21 chars, 126 bits):
  - Comparable to UUID v4
  - ~1% collision probability after 2.2 × 10^17 IDs

Nano ID (10 chars, 60 bits):
  - 1% collision probability after ~34 million IDs
  - Fine for small apps, risky for large-scale systems

General rule:
  - Under 1 million IDs total: 10+ characters is plenty
  - Under 1 billion IDs: 16+ characters
  - Planetary scale: 21+ characters (Nano ID default) or UUID

When to Use Each Format

• UUID v4: When you need maximum compatibility. Database columns typed as UUID, interoperability with external systems, or any context where the recipient expects a UUID. It's the safe default choice.
• UUID v7: When you need UUIDs as database primary keys and want to avoid index fragmentation. The time-sorted nature plays well with B-tree indexes in PostgreSQL, MySQL, and other relational databases.
• Nano ID: When you control both ends of the system and want shorter, cleaner IDs. Great for URL shorteners, invite codes, file names, and client-side generated IDs. Use the Random String Generator for even more customization options.
• CUID2: When you need IDs that are secure against enumeration attacks and you want them to start with a letter (valid as HTML IDs and CSS selectors). Good for user-facing identifiers in distributed systems.

For most applications, the choice comes down to two questions: do you need broad compatibility (choose UUID), or do you want shorter, more efficient IDs in a system you fully control (choose Nano ID)? If database sort order matters, UUID v7 is the best of both worlds. Generate and compare these formats yourself using the UUID Generator and Nano ID Generator.