What is a UUID?
A UUID (Universally Unique Identifier) is a 128-bit value used to label something without coordinating with a central authority. Because the space of possible values is astronomically large — roughly 3.4 × 1038 combinations — two independently generated UUIDs are effectively guaranteed never to collide. That makes them ideal for primary keys, request IDs, file names, and distributed systems where many machines mint identifiers at once.
UUIDs are written as 32 hexadecimal digits in five hyphen-separated groups, like f81d4fae-7dec-4d2a-8a1b-9c3f2e6b7a01. A few bits are reserved to encode the version (how the UUID was generated) and the variant. The two versions most relevant to modern applications are v4 and v7.
UUID v4: Fully random
Version 4 is the workhorse most developers reach for. Of its 128 bits, 6 are fixed for version and variant metadata, leaving 122 bits of pure randomness. There is no embedded timestamp, MAC address, or counter — just entropy from a cryptographically secure random source.
The strengths are obvious: excellent uniqueness, no information leakage, and trivial generation that needs no shared state. The values are completely opaque, so an outsider cannot infer when a record was created or guess neighboring IDs.
The weakness shows up in databases. Because v4 values are random, consecutive inserts land in scattered positions across a B-tree index. New rows do not append to the "end" of the index; they wedge into random pages. This hurts index locality, causes page splits and fragmentation, bloats the working set the database must keep in memory, and slows down bulk inserts. For a high-write table keyed on a v4 UUID, this overhead is real and measurable.
UUID v7: Time-ordered
Version 7 was designed specifically to fix the database problem while keeping the convenience of a random-looking identifier. Its layout puts a 48-bit Unix-millisecond timestamp at the front, followed by version/variant bits and roughly 74 bits of randomness.
Because the timestamp leads, v7 UUIDs generated over time are naturally sortable by creation order. Lexicographic string ordering matches chronological ordering. New inserts cluster at the high end of the index, so the B-tree grows by appending rather than fragmenting — dramatically better index locality and far fewer page splits.
Here is roughly how the bytes break down:
v7: | 48-bit ms timestamp | ver | rand-a | var | rand-b |
|<------ sortable ------>|<----- random tail ---->|
v4: | 122 random bits + 6 fixed version/variant bits |
|<------------- entirely unordered ----------------->|The random tail keeps v7 collision-resistant even when many IDs are created within the same millisecond. You get sortable, index-friendly keys without sacrificing practical uniqueness.
How to choose
Pick based on what the identifier needs to do, not on which version is "newer."
- Use v7 for database primary keys, event logs, message IDs, or anything you insert in order or sort by time. The time-ordering pays off directly in write throughput and index health.
- Use v4 when you need maximum opacity and must not leak timing information — public-facing tokens, password-reset links, API keys, or any ID an attacker could mine. A v7's embedded timestamp reveals when the record was created, which is sometimes a privacy or security concern.
A common pattern is to use v7 for internal primary keys and a separate v4 (or another opaque token) for anything exposed externally.
The other versions, briefly
Two older versions still appear in the wild:
- v1 — time-based, combining a timestamp with the host's MAC address and a clock sequence. It sorts by time but can leak the generating machine's hardware identity. v7 is the modern, privacy-safer replacement.
- v5 — name-based, deriving the UUID by hashing a namespace and a name with SHA-1. The same input always yields the same UUID, which is useful for deterministic, reproducible IDs. (v3 is the older MD5-based equivalent.)
Generate both with Formatly
Formatly's UUID Generator creates v4 and v7 identifiers instantly so you can grab exactly the kind you need — opaque randomness or sortable time-ordering — and copy them straight into your code or database seed. Generation happens entirely in your browser: nothing is uploaded and no values touch a server, so the IDs you create stay private to you. That client-side approach matters when the UUIDs are destined to become tokens, keys, or anything else you would not want logged by a third party.