Developer tools · UUID generator
UUID Versions 1 to 8 Explained: Which One Should You Generate?
· Background
uuid cryptography browser-apis
Eight versions share one format but solve different problems: time ordering, reproducibility, randomness or custom layouts. This post explains each and gives a decision path.
One format, eight recipes — why the version nibble matters when you pick a library function
The UUID standard defines a 128-bit format as thirty-six hexadecimal characters with hyphens. RFC 9562 defines eight distinct recipes—versions one through eight—for filling those bits with different patterns and meanings. The version nibble (first character of the third group) identifies which method produced the value, serving as a label. Choosing the wrong version means storing unnecessary temporal information, missing ordering guarantees for database performance, or misunderstanding identifier security roles. This post walks through each version, what concrete problem it solves, when developers encounter it in practice, and provides a decision framework for selecting the right version for your specific system requirements.
v1 and v6: time plus node — the original time-based layout and the reordered version that sorts correctly
Version 1 combines a 60-bit timestamp with a node identifier (originally a MAC address, though modern implementations use random values to avoid leaking hardware information). The timestamp records 100-nanosecond intervals since October 15, 1582. The node field can reveal when the identifier was generated and where it originated geographically, which is why modern implementations avoid MAC addresses. Version 6 rearranges the same timestamp and node information to improve sortability by moving high-order time bits to the front, making v6 UUIDs sort correctly in lexicographic order. If your application needs UUIDs that naturally sort by creation time with superior index locality, v6 is the modern choice.
v2: DCE Security — the rarely used variant that embeds POSIX identifiers
Version 2 is rarely used in new systems. It embeds POSIX user or group identifiers into the UUID layout, making it useful only in legacy environments where those identifiers carry organizational meaning. The v2 design assumes a specific computing model (DCE Security) that is uncommon in modern distributed systems. Most organizations associate UUIDs with users or groups in their application layer through database joins or lookup tables, not by encoding the user ID into the identifier itself. This separation of concerns makes it easier to change authorization models, migrate user data, and maintain audit trails. Encoding credentials directly into UUIDs creates tight coupling and makes systems harder to evolve.
v3 and v5: name-based — deterministic IDs hashed from a namespace and a name with MD5 or SHA-1
Versions 3 and 5 UUIDs are deterministic: the same namespace and name always produce the same identifier, ideal for representing stable mappings from external data. Version 3 uses MD5 and version 5 uses SHA-1 as hash algorithms, reflecting their respective ages and adoption. When a customer record arrives for import, a v5 UUID derived from a fixed namespace will be identical across multiple import runs, preventing duplicate records. This determinism means the UUID is reproducible and predictable to anyone who knows the namespace and input. The practical value shines in data integration scenarios: reconciling customer records from multiple systems, preventing duplicates in recurring imports, and assigning stable IDs to items.
v4: random — 122 bits from a CSPRNG and the default choice when ordering does not matter
Version 4 is the default choice when ordering is not required and you want independent generation without central coordination. A v4 UUID is composed of 122 bits from a cryptographically secure random source, with six bits set to fixed values (version nibble 4 and RFC 9562 variant bits 10). The randomness is the entire point: each call produces a different value, collisions remain vanishingly unlikely, and no external state or coordination is required. It is the version ToolAcre generates using crypto.randomUUID() or crypto.getRandomValues(). This version is suitable for object references, unstructured data, and most roles outside of primary keys or sorting contexts.
v7 and v8: Unix time and custom — the modern time-ordered version for database keys and the escape hatch for bespoke layouts
Version 7, standardized in RFC 9562, brings modern time-ordered properties into the UUID format. It uses a 48-bit Unix millisecond timestamp, 12 bits of sub-millisecond precision, and 62 random bits combined. The Unix millisecond timestamp is good until the year 10889, making it suitable for systems. The result sorts correctly in lexicographic order and fits in a standard 128-bit UUID column without special handling or encoding conversion. If your application needs identifiers that sort by creation time within the standard UUID format, v7 is the current best practice. Version 8 is a standardized catch-all for implementation-defined formats, useful only if you need specific bit layouts not covered by v1-v7.
Worked example — a decision path applied to three scenarios: a public API reference, a primary key, and a stable ID for imported records
Three real-world scenarios illustrate version selection: First, a public API reference must be stable across API instances, must not leak creation time, and must be the same across server restarts so different instances generate the same reference for the same document. Use v5 with a stable namespace and document name. Second, a primary key for a continuously growing table needs to be unique, should not cause index fragmentation, and must be generatable by any application instance without central coordination. Use v7 for sortable identifiers with standard UUID ecosystem support. Third, archived records requiring stable lookup need immutable identifiers.
Takeaway: pick by property, not by habit — the ToolAcre generator produces random UUIDs from the browser's CSPRNG for the cases that call for v4
Version selection follows from your schema design and system requirements, not from convention or familiarity. Random UUIDs (v4) are the default because they require no state or coordination and produce independent identifiers suitable for most roles. Time-ordered versions (v6, v7) solve index-locality problems at the cost of temporal information leakage or clock synchronization requirements. Deterministic versions (v3, v5) prevent duplicate imports and enable stable external mappings at the cost of predictability—anyone who knows your namespace can recompute them. ToolAcre generates random v4 UUIDs from the browser's cryptographically secure generator. When you need a different version, the well-formed check confirms identifiers parse as valid.