UUID v1, v4 & v7 Generator

When to reach for a UUID

Every distributed system eventually faces the same question: how do two services running on different machines create identifiers that will never collide? Database auto-increment integers fail the moment you split writes across replicas. Random strings work in practice, but without a shared format, parsing and comparing them across languages adds unnecessary friction. UUIDs solve both problems with a 128-bit identifier that requires no central authority and no coordination between services.

A UUID is 32 hexadecimal characters arranged into five groups by hyphens, following the 8-4-4-4-12 pattern. The standard, originally defined in RFC 4122 and updated by RFC 9562 in 2024, specifies multiple versions with different properties.¹² Choosing the right version depends on whether you need pure randomness, chronological sortability, or backward compatibility with older systems that expect v1 identifiers.

UUID v4: the random standard

UUID v4 is the version most developers reach for first, and for good reason: it requires no input beyond a source of randomness, it is supported by every UUID library in circulation, and its 122 bits of entropy make collisions effectively impossible at any realistic scale. The tool generates each v4 UUID using your browser's CSPRNG, so the output is suitable for session tokens, database keys, and public-facing identifiers alike.

The format is simple by design. The version nibble and variant bits occupy only 6 of the 128 bits, leaving the remaining 122 to the random source. That is why the character at position 13 in any formatted v4 UUID is always 4, and the character at position 17 is always 8, 9, a, or b. These fixed positions are a useful sanity check when you are debugging a system that stores or compares UUIDs, because a malformed identifier is immediately obvious from a single character lookup.

How v4 UUIDs are constructed

UUID v4 fills 122 of its 128 bits with cryptographically random data. The remaining 6 bits are fixed: 4 bits encode the version (0100 in binary) and 2 bits mark the variant field required by the RFC.³ Because of this, the character at position 13 in any formatted v4 UUID is always 4. The character at position 17 is always 8, 9, a, or b, reflecting the 2-bit variant prefix.

Your browser generates v4 UUIDs using the platform's CSPRNG, the same source of entropy that secures TLS handshakes. Calling crypto.randomUUID() draws from the operating system's random pool, not from Math.random(), which is not cryptographically secure and must never be used for tokens, identifiers, or anything security-sensitive.⁴ The native API is available in all modern browsers and in Node.js.

With 122 bits of entropy, the probability of generating the same v4 UUID twice within a set of one trillion identifiers is roughly 1 in 10 trillion.⁵ At any realistic production scale, collisions simply do not occur. You can generate and store v4 UUIDs freely without a uniqueness check at the application layer.

UUID v7: time-ordered for databases

UUID v7 is the newest version in the RFC, added specifically to address the performance problems that v4 causes in database indexes. By encoding a millisecond timestamp in the leading 48 bits, v7 UUIDs sort chronologically as plain strings, which means new inserts always land at the end of a B-tree index rather than at a random page. If you are generating identifiers outside the database and want the benefits of decentralised creation without the index fragmentation cost, v7 is the current best practice.

Why v7 solves the index fragmentation problem

UUID v7 was introduced in RFC 9562 to solve a performance problem that v4 creates in database indexes.¹ Its first 48 bits encode a Unix millisecond timestamp in big-endian order. Four version bits follow, then 12 random bits, then 2 variant bits, then 62 random bits. The result is a UUID that sorts chronologically when compared as a plain string. Uniformly random bytes fragment B-tree indexes because every v4 insert lands at a random position in the tree, triggering page splits and write amplification under high-throughput workloads; UUID v7 inserts consistently at the end of the index, the same way auto-increment integers do, without a centralized ID sequence.

The first 12 hexadecimal characters of a v7 UUID encode the creation timestamp.³ Interpreting them as a 48-bit big-endian integer gives you Unix milliseconds since the epoch. The character at position 13 is always 7, confirming the version. For new tables where you control the primary key format, v7 is the current best practice when your system generates keys outside the database itself.

UUID v1: time-based with a node field

UUID v1 encodes a 60-bit timestamp counting 100-nanosecond intervals since October 15, 1582 (the date of the Gregorian calendar reform).⁶ The node field, occupying the final 48 bits, was originally designed to hold the MAC address of the generating machine. This ensured that two machines generating identifiers at the same instant would still produce distinct values without any coordination. The timestamp byte order places the least significant bits first, so v1 UUIDs do not sort chronologically as strings even though they contain a timestamp.

Modern systems generally avoid v1 in new designs. Using a real MAC address embeds a hardware identifier into every UUID, which creates a privacy concern when those identifiers appear in logs, URLs, or API responses. For both reasons, v7 is the preferred time-based option in RFC 9562. Since browsers expose no MAC address through any API, this tool follows the RFC 4122 recommendation for restricted environments: the node field uses 6 cryptographically random bytes with the multicast bit set to 1.⁶ The result is a valid v1 UUID that carries no identifying hardware information.

Display formats

A UUID is a single 128-bit value, but the way it is written down matters as much as the value itself because different consumers expect different conventions. The tool exposes five common representations, each of which you can copy with one click, so the generated identifier drops into your target system without any manual reformatting.

Choosing the right format for your use case

The same 128-bit value can be rendered in several conventions depending on what the consuming system expects. Lowercase with hyphens is the canonical RFC format and the most portable choice for APIs, log files, and databases. UPPERCASE is required by some Windows APIs and older enterprise systems that predate the RFC. The no-hyphen format removes all four hyphens, producing a 32-character string that some ORMs and databases use internally to reduce storage overhead on indexed columns.

Braces formatting, common in Microsoft COM-era specifications, wraps the standard form in curly braces. The URN format prefixes the UUID with urn:uuid:, which is the registered URI scheme defined in RFC 4122.² Use the URN form when the identifier needs to appear in an XML document, an RDF graph, or another context that requires a globally resolvable URI. Switching between formats here reformats the stored value client-side without re-generating. The underlying UUID is identical in all five representations.