UUID Versions Reference
A UUID is a 128-bit identifier with a standard textual representation. Version choice determines how its bits are generated, but authorization and database constraints still remain application responsibilities.
| Version | Source | Typical property |
|---|---|---|
| v1 | Time and node information | Time-based; can expose generation metadata. |
| v3 | Namespace and name with MD5 | Deterministic for the same namespace and name. |
| v4 | Random or pseudorandom bits | Simple, widely supported random identifiers. |
| v5 | Namespace and name with SHA-1 | Deterministic for the same namespace and name. |
| v7 | Unix time in milliseconds plus random bits | Time-ordered with better index locality. |
UUID v4
Version 4 uses random bits except for version and variant fields. Generate it with a cryptographically secure random source supplied by the platform. Its large random space makes accidental collision extremely unlikely under normal use, but a database unique constraint should still enforce identity. Do not build v4 values from timestamps, process IDs, or a weak random generator.
UUID v7
Version 7 places a Unix-time millisecond value near the beginning and adds random bits. Lexicographic or binary ordering can therefore follow generation time more closely than v4, improving locality in some database indexes. It also exposes approximate creation time. Implement monotonic generation carefully when many IDs are produced in one millisecond and use a well-tested library.
UUID v1 privacy considerations
Version 1 is time-based and historically incorporates node information derived from a hardware address or a randomized node identifier. Its visible timestamp and node fields can disclose more generation metadata than an application expects. Prefer v4 or v7 for new general-purpose IDs unless interoperability requires v1 and its privacy properties are understood.
Namespace UUIDs: v3 and v5
Versions 3 and 5 deterministically derive an identifier from a namespace UUID and a name. They are useful when the same canonical input must produce the same ID across systems. Normalize the name exactly once and keep namespace ownership stable. These versions do not hide the input or provide a password hash; predictable inputs remain predictable.
Text, binary storage, and comparison
The familiar text form contains 32 hexadecimal digits and four hyphens, for example 550e8400-e29b-41d4-a716-446655440000. Store as a native UUID or 16-byte type when the database supports it, or use canonical text consistently. Avoid mixing byte-order conventions across drivers. Text comparisons are normally case-insensitive for hexadecimal, but emit lowercase canonical form for consistency.
Validation and security
Validate shape, variant, and permitted version at the trust boundary. A syntactically valid UUID does not prove that a record exists or belongs to the caller. Do not expose sequential business meaning through authorization decisions, and do not rely on identifier unpredictability as access control. Apply tenant and resource permission checks every time.
Frequently Asked Questions
Which version is random?
UUID v4 is the common random choice.
Why choose v7?
It provides time ordering and improved index locality.
Does valid syntax prove existence?
No. Validate authorization and ownership separately.