7 min read
2026-03-11
RFC 4122 standard. Format: `xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx` (36 characters including hyphens).
**Versions:**
| Version | Method | Application |
|---|---|---|
| v1 | Time + MAC address | Outdated, insecure |
| v4 | Random bytes | The most common |
| v5 | SHA-1 hash | Deterministic |
| v7 | Unix-time + random | Sortable (new standard) |
###ULID (Universally Unique Lexicographically Sortable Identifier)
`01ARZ3NDEKTSV4RRFFQ69G5FAV` (26 characters)
The first 10 characters are milliseconds of Unix time
The last 16 characters are random
Lexicographically sortable — ideal for databases
`V1StGXR8_Z5jdHi6B-myT` (21 characters by default)
UUID is 37% more compact
Customizable length and alphabet
URL safe by default
Popular in front-end development
| UUID v4 | UUID v7 | ULID | NanoID | |
|---|---|---|---|---|
| Length | 36 | 36 | 26 | 21 |
| Sortable | No | Yes | Yes | No |
| URL-safe | No | No | Yes | Yes |
| Timestamp | No | Yes | Yes | No |
| DBMS support | Excellent | Good | Average | Weak |
UUID v4 — standard choice for most tasks
UUID v7 — new projects with databases (better indexed)
ULID — when sorting by creation time is important
NanoID — short IDs in URLs, session tokens, frontend
UUID as a primary key creates fragmentation of the B-Tree index. Solutions:
Use UUID v7 or ULID (monotonically increasing)
Store UUID as BINARY(16), not VARCHAR(36)
In PostgreSQL, use uuid type (native)
Generate UUID of any version in UUID Generator.
See also: Password generator, Hash generator, Test data generator