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.

The versions this tool does not generate

Three versions appear above, because three cover what a paste-and-copy page can do. The rest of the version map serves different jobs. From a namespace and a name, versions 3 and 5 derive a UUID deterministically, through MD5 and SHA-1 hashing respectively, so the same input pair always produces the same identifier, which serves reproducibility rather than randomness. Version 6 takes the v1 timestamp-and-node layout and rearranges its fields into big-endian order, so the value sorts chronologically the way v7 does. Version 8 reserves its bits for custom, application-defined layouts, a space for implementations that need to embed their own meaning in the 128 bits.

So why only three? V4 covers the random default most systems want, v7 the modern database key, and v1 the legacy expectation older interfaces still carry. Each remaining version belongs to a context a generator page cannot follow. For name-based derivation, the work lives with the code that owns the namespace, because the same canonical name has to reach the hash for the result to reproduce, which is a job for a program rather than a paste box. A custom v8 layout belongs to the system that defined it, because only that system knows what its bits mean. The three rows above answer what a paste page can answer; the rest is intentionally out of scope.

The same generation in code

In most systems, a UUID is born in code, and the page above is only one route to one. Every mainstream language ships the same capability: Python's standard uuid module generates versioned UUIDs through functions like uuid4(),³ and Node's crypto module carries the same randomUUID() call this page uses, along with a randomUUIDv7() sibling.⁴ The major database engines expose UUID functions of their own. For a quick one-off paste, the browser route wins; the code route wins the moment the identifier is born inside the process that stores it, because generation and insert happen in one place.

Whichever route generates the value, one quick check travels with it. The version nibble at position 13 names the generation family at a glance, the same marker the reference box at the bottom of this page lists, so you can identify any arriving value before you trust it. Before wiring a generator call into a schema, confirm which version it emits instead of assuming. The routes genuinely differ: Python's module names a function for the version you want, and Node's crypto module exposes one call for v4 and another for v7, so the version you get is a property of the call you picked rather than of UUIDs in general.³⁴

There is a boundary to state plainly. This page generates one UUID per version on every Regenerate All click, three values in total, and offers no count field of any kind; the shape fits a quick look, not a bulk load. A handful of identifiers is a few clicks. For a batch of hundreds, the code route described above is the right home, where a loop calls the generator function directly and writes the results where they live. No batch feature is claimed here, and none is needed for the job this page does: seeing the three version formats side by side and copying the one you want.

Generating UUIDs in Bulk

When you need more than one identifier at a time, for test fixtures or a data import, clicking once per value stops being practical. The guide below explains what the Regenerate All action produces in one click, a fresh v1, v4 and v7 value side by side, where generating a batch is actually useful, and why every value it creates is generated locally in your browser.

Before: a test fixture file needs five distinct, stable user IDs that will not change between test runs.

Clicking Regenerate All five times and copying the V4 value each time produces five independent UUIDs you can hardcode directly into the fixture file, with no coordination needed between them.

Before: an import script needs to know each row's primary key ahead of time so it can reference those IDs in a related table.

Generating and copying a V4 value per row here, before running the import, gives you a fixed ID to embed in both the primary import and the related table's foreign-key references, rather than letting the database assign one you would have to look up afterward.

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.

A paste or a database row can be checked by shape alone, before any tool runs. A well-formed UUID passes three checks in one glance: it holds the 8-4-4-4-12 group shape, every character is hexadecimal, and the nibble at position 13 names a real generation family, the same marker the reference box at the end of this page lists. Break the group shape, carry a character outside the hexadecimal set, or put an impossible digit at position 13, and the value is malformed before any deeper check runs. Reading the marker at position 17 catches the same class of problem from the variant side.

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.

The two Microsoft-flavored formats on this page carry a name with their lineage. GUID, short for Globally Unique Identifier, is the Microsoft ecosystem's word for the same 128-bit value: the standard that defines UUIDs names them one and the same, so a GUID and a UUID are the same identifier under different naming. From that lineage come the UPPERCASE and Braces spellings on this page. What that means for you is simple: choosing a format is choosing a convention for the consumer, never a different identifier, and all five renders of one generated value are that one value.

Case is the last question the UPPERCASE toggle raises, and the answer is short: case never touches the bits. A UUID's letters are hexadecimal digits, so changing case changes only the spelling of the string, never the 128-bit value it names. Under the RFC's string grammar, all uppercase, all lowercase, and mixed case are equally legal, so both spellings of one value are the same UUID. The practical rule is to generate in one case, compare in that same case, and where a downstream system compares strings raw, match its convention instead of mixing spellings. The Standard format here spells the value in lowercase; the UPPERCASE toggle changes the spelling, never the value.