When you need a unique identifier in your app, you have options. UUID v4 is the classic choice, but UUID v7, ULID, and NanoID each solve specific problems better. Here's when to use each.
UUID v4 — The Classic (Random)
UUID v4 is 128 bits of cryptographically random data, represented as:
550e8400-e29b-41d4-a716-446655440000
Format: 36 characters (32 hex digits + 4 dashes)
Pros:
- Universal support — every database, ORM, and language has a UUID v4 library
- Cryptographically unpredictable — safe to expose in URLs
- Zero configuration required
Cons:
- Not sortable by creation time — random values cause index fragmentation in B-tree databases
- Long and contains dashes — verbose in URLs and logs
Use when: You need a well-supported, general-purpose unique ID and don't need time-ordering.
UUID v7 — The Modern Choice (Time-Ordered)
UUID v7 combines a Unix timestamp (millisecond precision) with random bits:
01961f2f-1234-7abc-8def-123456789abc
The first 48 bits encode the timestamp — UUIDs generated later sort higher. This matters for database performance.
Pros:
- Naturally sortable — insert order matches lexicographic order
- Fast B-tree index inserts — no random page splits like v4
- Part of the RFC 9562 standard (2024)
- Almost universally unique (collision probability is negligible)
Cons:
- Not yet in all languages/ORMs by default (check your version)
- Exposes approximate creation timestamp (rarely a concern)
Use when: You're storing UUIDs as database primary keys. The sortability dramatically improves index performance at scale.
ULID — Sortable, Human-Friendly
ULID (Universally Unique Lexicographically Sortable Identifier):
01ARZ3NDEKTSV4RRFFQ69G5FAV
Format: 26 characters in Crockford base32 (no dashes)
Pros:
- Lexicographically sortable (timestamp-first, like UUID v7)
- Shorter than UUID — 26 chars vs 36
- URL-safe, no special characters
- Crockford base32 is human-readable (no ambiguous chars like O, I, L)
Cons:
- Not an RFC standard — requires a library (unlike UUID which is in most stdlib)
- Less universal than UUID — not all databases have native ULID support
Use when: You want sortable IDs with a readable format. Popular in event-sourced systems and distributed logs.
NanoID — Short and URL-Safe
NanoID generates compact random IDs:
V1StGXR8_Z5jdHi6B-myT
Format: 21 characters by default (configurable), URL-safe alphabet
Pros:
- Much shorter than UUID
- URL-safe by default (no dashes or special encoding needed)
- Configurable length — go shorter (but understand the collision risk)
- Fast and lightweight
Cons:
- Not sortable
- Not an RFC standard
- Length choice affects collision probability — 21 chars is ~UUID-level security
Use when: You need short, URL-safe identifiers for web-facing resources (share links, short IDs in URLs, API keys). Popular in React and Vue projects.
Quick Decision Guide
| Need | Use |
|---|---|
| General-purpose, maximum compatibility | UUID v4 |
| Database primary key | UUID v7 |
| Sortable IDs with readable format | ULID |
| Short, URL-safe, web-facing IDs | NanoID |
| Reproducible IDs from a name | UUID v5 |
Generating UUIDs
To generate UUID v4 in the browser or Node.js:
// Browser / Node.js 19+
const id = crypto.randomUUID();
// Python
import uuid
id = str(uuid.uuid4())
// Go
import "github.com/google/uuid"
id := uuid.New().String()
For quick generation without writing code, SnappyTools UUID Generator generates v4 UUIDs in bulk (1–100 at a time) with one-click copy — useful when seeding databases or creating test fixtures.
Summary: Use UUID v7 for database primary keys. Use UUID v4 for compatibility. Use NanoID for short web URLs. Use ULID when you want readable sortable IDs without database friction.
Top comments (0)