What is a UUID?
UUIDs explained: the 5-part structure, v1 vs v4 vs v7 vs ULID, uniqueness guarantees, and when to choose UUID over auto-increment.
A UUID (Universally Unique Identifier) is a 128-bit label used to identify information in computer systems. Its design goal is that it can be generated independently — without a central authority — and still be unique across all space and time with overwhelming probability.
UUIDs are standardized in RFC 9562 and written as 32 hexadecimal characters separated by hyphens in the format xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version digit and N encodes the variant.
Anatomy of a UUID
Total: 128 bits — 32 hex characters + 4 hyphens = 36 characters.
UUID versions
| Version | How generated | Sortable | Use when |
|---|---|---|---|
| v1 | Timestamp + MAC address | Yes (roughly) | You need time-ordered IDs and don't mind exposing MAC addresses |
| v3 | MD5 hash of a namespace + name | No | Deterministic UUIDs from a name (legacy) |
| v4 | 122 bits of random data | No | General purpose — the most widely used version today |
| v5 | SHA-1 hash of a namespace + name | No | Deterministic UUIDs from a name (preferred over v3) |
| v7 | Unix timestamp + random data | Yes — lexicographically | Database primary keys where chronological ordering matters |
When in doubt, use v4 for general identifiers and v7 if you need UUIDs that sort correctly (e.g. as database primary keys with B-tree indexes).
This site's UUID Generator can produce a batch of v4, v7 or ULID identifiers instantly, useful for seeding test data.
UUID v7 vs ULID: two ways to get sortable IDs
v7 and ULID solve the same problem with the same core idea: a random-looking ID that still sorts in creation order, built by leading with a 48-bit millisecond timestamp and filling the rest with random bits. They differ in encoding, not in the guarantee they give you.
A v7 UUID's 128 bits break down into a 48-bit timestamp, a fixed 4-bit version field (0111), 12 bits of random data, a fixed 2-bit variant field (10), then a final 62 bits of random data, written in the standard 32-hex-digit, hyphenated form. ULID skips the version and variant bits entirely: a 48-bit timestamp plus 80 bits of randomness, encoded as 26 characters of Crockford's base32 (case-insensitive, excludes the letters I, L, O and the digit that looks like O, to avoid transcription errors), with no hyphens and 10 fewer characters than a hyphenated UUID string.
| UUID v7 | ULID | |
|---|---|---|
| Standard | RFC 9562 | Community spec, not an RFC |
| Encoding | 32 hex digits, hyphenated | 26-char Crockford base32, no hyphens |
| Drop-in UUID column? | Yes, a valid RFC 4122 UUID | No, needs its own text or binary(16) column |
| Random bits | 74 | 80 |
One nuance neither spec makes obvious up front: generating many IDs in the same millisecond with pure randomness gives no ordering guarantee within that millisecond, and timestamp collisions are common under any real bulk-insert or seed-data workload. Both specs address this the same way (RFC 9562 calls it the "Monotonic Random" method): instead of drawing fresh random bits every time, a generator that sees the clock hasn't advanced since its last ID increments the previous random value instead of redrawing it, so IDs minted in the same millisecond still sort in generation order. A generator that skips this, including naive "timestamp + Math.random()" implementations, will produce technically-valid but unsorted IDs for any burst of inserts that lands in one millisecond. That quietly defeats the entire reason to pick v7 or ULID over v4 in the first place.
UUID vs auto-increment IDs
| UUID (v4) | Auto-increment integer | |
|---|---|---|
| Globally unique | Yes | Only within one table |
| Merge-safe | Yes — no conflicts when merging databases | No — IDs collide |
| Predictable / guessable | No — opaque to outside users | Yes — sequential |
| Index performance | Slower — random values cause B-tree fragmentation | Faster — sequential |
| Storage | 16 bytes (binary) or 36 bytes (string) | 4–8 bytes |
| Expose record count | No | Yes — users can infer total records |
UUID v7 largely eliminates the index performance issue because it is time-ordered, combining the global uniqueness of UUIDs with index performance close to auto-increment.
The nil and max UUIDs
Two special UUIDs are defined by the standard:
- Nil UUID — all zeros:
00000000-0000-0000-0000-000000000000. Used as a "no value" sentinel, similar tonull. - Max UUID — all
fs:ffffffff-ffff-ffff-ffff-ffffffffffff. Useful as an upper bound in range queries.
Are UUIDs truly unique?
UUID v4 has 122 bits of randomness, giving approximately 5.3 × 1036 possible values. The probability of generating a duplicate when producing 1 billion UUIDs per second for 100 years is still negligible — far smaller than the probability of a hardware error occurring in the same period. In practice, UUID v4 collisions do not happen.
UUID v5 deterministically produces the same UUID for the same input, which is useful for stable, reproducible identifiers. It uses SHA-1 hashing internally, though the security concerns around SHA-1 collisions do not apply here since the goal is uniqueness, not collision resistance against adversaries.
Frequently asked questions
In practice, yes. UUID v4 has 122 bits of randomness, giving approximately 5.3 × 10³⁶ possible values. The probability of generating a duplicate when producing 1 billion UUIDs per second for 100 years is negligible, far smaller than the probability of a hardware failure in the same period.
UUID collisions happen in theory (the birthday problem applies), but the expected number of UUIDs you must generate before seeing a collision exceeds 2.7 × 10¹⁸. In practice, UUID v4 collisions do not happen.