128 bits, no coordination required
A UUID (Universally Unique Identifier) is a 128-bit value, conventionally written as 32 hex digits in five hyphenated groups: f47ac10b-58cc-4372-a567-0e02b2c3d479. The defining property is that it can be generated independently, on any machine, with no central authority or database round-trip, while still being collision-resistant enough for practical use — for random UUIDs (v4), the chance of two ever colliding is astronomically small (you'd need to generate roughly a billion UUIDs per second for about 85 years before a 50% chance of one collision).
The version is encoded directly in the string: the first character of the third group (4372 above) reveals it — 4 means version 4.
Version 4: fully random
f47ac10b-58cc-4372-a567-0e02b2c3d479
^
version nibble = 4
122 of the 128 bits are random (6 bits are fixed to identify the version and variant); the rest come from a cryptographically secure random source. This makes v4 the simplest, most widely supported version — no timestamp, no machine identifier, nothing derivable from the value itself. The tradeoff: because they're random, v4 UUIDs have no natural sort order, which matters for database performance.
Version 7: random, but time-ordered
Version 7 (standardized in 2024) embeds a 48-bit Unix millisecond timestamp in the leading bits, with the remainder random:
018e5a4b-8c3d-7000-8a1b-3c4d5e6f7890
└────timestamp────┘ ^
version nibble = 7
Because the timestamp occupies the leading bits, v7 UUIDs generated later sort after earlier ones lexicographically — unlike v4, which sorts in effectively random order. This directly benefits databases: most relational databases store primary keys in an index structure (commonly a B-tree) that performs significantly better with sequential inserts than random ones. Random v4 keys cause new rows to insert at random points throughout the index, causing page splits and fragmentation; time-ordered v7 keys insert at the end, much like a traditional auto-incrementing integer, while still being generatable without coordination.
When to use which
| Need | Use |
|---|---|
| Maximum simplicity, no ordering requirement | v4 |
| Primary key in a high-write relational database | v7 |
| Obscuring creation time (e.g., not leaking when a resource was made) | v4 (v7 embeds a readable timestamp) |
| Log/event IDs where chronological sortability helps debugging | v7 |
Other versions worth knowing
- v1 — timestamp + MAC address of the generating machine. Rarely used today because embedding a MAC address is both a privacy leak and unnecessary given better alternatives.
- v3 / v5 — deterministic, generated from a namespace and name via MD5 (v3) or SHA-1 (v5) hashing — the same input always produces the same UUID, useful for generating a stable ID from an existing identifier (e.g., a URL) without a lookup table.
Common mistakes
- Using v4 as a primary key on a very large, high-write table without considering the index fragmentation cost — v7 (or a database-native sequential UUID type) avoids this while keeping the no-coordination benefit.
- Assuming UUIDs are cryptographically secure tokens. v4's randomness is suitable for uniqueness, but a UUID isn't designed or vetted as a security token (like a session ID or API key) — use a purpose-built random token generator for those.
- Parsing the version nibble incorrectly. It's always the first character of the third hyphenated group — mixing this up leads to misidentifying which version a given UUID actually is.
- Treating v1/v3/v5 as "more secure" because they're less common. They're less common because they solve different problems (embedding identifiable data, or determinism) — not because they're more robust.
FAQ
Are UUIDs guaranteed to be unique?
Not mathematically guaranteed, but collision probability for v4 is low enough to be treated as unique in practice — a birthday-paradox calculation shows you'd need an enormous, sustained generation rate to meaningfully risk a collision.
Why would I choose v7 over v4?
v7 embeds a timestamp so IDs sort chronologically, which improves insert performance in database indexes that prefer sequential keys — v4's IDs insert in random order, fragmenting those indexes over time.
Does a v7 UUID reveal when it was created?
Yes — the leading bits are a readable Unix timestamp, which is a meaningful difference from v4 if you don't want creation time to be inferable from the ID itself.
Can I generate a UUID that's the same every time for the same input?
Yes — v3 (MD5-based) and v5 (SHA-1-based) are deterministic: given the same namespace and name, they always produce the identical UUID, unlike v4 or v7.
Generate v4 and v7 UUIDs instantly with the UUID Generator — generated entirely in your browser, nothing sent anywhere.