Introduction
Distributed applications need identifiers that can be created without asking one central database for the next number. UUIDs appear in API resources, database rows, event messages, file names, tracing systems and idempotency keys.
Different UUID versions make different trade-offs. Version 4 emphasizes randomness, version 1 combines time with node information, and version 7 places Unix time before random bits for sortable modern identifiers. The utily.tools UUID Generator exposes these versions and common formatting options.
A 128-bit identifier with versioned semantics
A UUID contains 128 bits, usually displayed as 32 hexadecimal digits in groups of 8-4-4-4-12. Specific bits encode the version and variant, leaving the remainder to time, randomness, counters or node data depending on the version.
Uniqueness is probabilistic or construction-based rather than a guarantee from a global registry. With properly generated v4 values, the available random space makes collisions extraordinarily unlikely. UUIDs still require correct randomness and should normally retain a unique database constraint.
Technical foundations and behavior
Generation begins with 16 bytes. The version nibble is written into byte 6 and the RFC variant into byte 8. Formatting only changes presentation; uppercase and hyphen removal do not alter the underlying identifier.
UUID v4
Version 4 uses 122 random bits after version and variant markers. Cryptographically secure random bytes are essential. Math.random is unsuitable because its internal state and distribution are not designed for identifier security.
UUID v1
Version 1 encodes a timestamp, clock sequence and node identifier. Its ordering and embedded metadata can be useful but may reveal creation time and historically a network address, which creates privacy concerns.
UUID v7
Version 7 begins with a 48-bit Unix timestamp in milliseconds followed by random data. Values generated later generally sort later, improving locality in B-tree indexes compared with fully random v4 keys. Implementations still need a strategy for multiple IDs within the same millisecond and clock rollback.
Real-world applications
Offline resource creation
A mobile client can assign an ID before synchronization, avoiding a round trip solely to reserve an identifier.
Event-driven systems
Events created by many producers receive independent IDs used for tracing, deduplication and replay.
Database primary keys
UUID v7 offers distributed creation with time-ordered insertion, often reducing index fragmentation compared with v4.
Standards and deeper technical reference
RFC 9562 replaced RFC 4122
UUIDs are 128-bit identifiers standardized by the IETF. RFC 9562, published in 2024, obsoletes RFC 4122, clarifies byte order and existing versions, and standardizes versions 6, 7 and 8. The familiar text form contains 32 hexadecimal digits grouped 8-4-4-4-12. The four version bits occupy bits 48 through 51 and the IETF variant begins with binary 10 in bits 64 and 65.
A UUID is designed to make collisions negligibly likely without a central allocator; it is not proof of authenticity, authorization or randomness. Systems should store all 128 bits and avoid parsing application meaning unless the selected version defines it.
| Version | Source | Properties and recommended use |
|---|---|---|
| v1 | Gregorian timestamp + clock sequence + node | Time-based legacy format; can expose time and node information |
| v3 | Namespace + name hashed with MD5 | Deterministic legacy name UUID; MD5 does not make it a security token |
| v4 | 122 random or pseudorandom bits | General opaque identifiers when generated by a CSPRNG |
| v5 | Namespace + name hashed with SHA-1 | Deterministic name UUID with broader use than v3 |
| v6 | Reordered v1 timestamp | Database-friendly time order while retaining v1 semantics |
| v7 | 48-bit Unix milliseconds + 74 variable bits | Preferred time-ordered UUID for new systems |
| v8 | 122 implementation-defined bits | Custom format; uniqueness depends entirely on its profile |
Version 4 collision probability and random generation
UUIDv4 fixes six version and variant bits and leaves 122 random bits. With n independently generated UUIDs, the birthday approximation gives collision probability about n² / 2^123 while the probability is small. Even one billion identifiers leaves an extremely small theoretical probability, but a broken or repeated random seed can dominate that math.
Browser generation should use crypto.randomUUID or crypto.getRandomValues, never Math.random. Random UUIDs remain guessable only to the extent of their entropy; they are not a substitute for access control, and exposing one may still leak the existence of a record.
Version 7 layout, sorting and monotonicity
UUIDv7 places an unsigned 48-bit Unix timestamp in milliseconds at the most significant end, followed by the version, 12 rand_a bits, the variant and 62 rand_b bits. Lexicographic byte order therefore groups values chronologically and usually improves B-tree locality compared with v4.
Several UUIDs created within one millisecond can use random bits, a counter or a sub-millisecond fraction according to RFC 9562. Implementations must handle clock rollback and counter overflow explicitly. The timestamp is observable, so v7 should not be used when creation-time disclosure is unacceptable.
Primary specifications and references
- RFC 9562: Universally Unique IDentifiersIETF / RFC Editor
- Web Cryptography APIW3C
- ECMAScript crypto.randomUUID Web API definitionW3C Web Cryptography Working Group
Conclusion
UUIDs solve decentralized identification, but their versions are not interchangeable. Version 4 is simple and private, version 1 exposes time-oriented structure, and version 7 adds modern sortability.
I prefer v7 for new distributed database keys when ecosystem support is available, and v4 for opaque identifiers where ordering is irrelevant. Generate test sets with the utily.tools UUID Generator and explore more site articles about hashes, timestamps and secure randomness.