UUID generator

What is a UUID?

A Universally Unique Identifier is a 128-bit value designed so that any party can generate one without coordination and still be confident the result will not collide with any other UUID anywhere. UUIDs are written as 32 hex digits grouped with hyphens — xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx — where M is the version and the high bits of N identify the variant.

UUIDs are standardized in RFC 9562 (2024), which obsoletes RFC 4122. The new RFC introduces v6, v7, and v8 alongside earlier versions, with v7 addressing the ordering problems of random UUIDs in databases.

How it works

The version digit selects how the bits were generated. v4 fills 122 bits with cryptographically random data — the result is statistically impossible to collide for any realistic system. v7 packs a 48-bit Unix-millisecond timestamp into the high bits and 74 random bits into the rest, producing IDs that are still globally unique but also sort by creation time. v1 combined the host MAC address with a clock value; it leaks both and is rarely used today.

The variant bits identify the layout (the most common is the RFC 9562/4122 variant). The hyphens are part of the canonical text form, but databases often store the underlying 16 raw bytes for efficiency and convert to text only on display.

When to use this tool

• Generating database primary keys that do not depend on a central sequence.
• Idempotency keys for retryable HTTP requests.
• Request IDs and trace IDs in distributed systems.
• Names for files, S3 objects, or message-queue records that must not collide.
• Validating or inspecting an existing UUID — confirming version, variant, and (for v7) the embedded timestamp.

Common pitfalls

• v4 looks completely random in a B-tree index, which destroys insert locality and causes severe write amplification on large tables. v7 gives you uniqueness plus time-ordered insertion at no extra cost.
• v1 leaks the host MAC address and the moment of creation. Avoid in contexts where you do not want clients to learn either.
• “Random enough” depends on the source. Math.random() is not cryptographically secure — use crypto.randomUUID() or an equivalent CSPRNG-backed generator.
• Encoding mismatches. Some databases store UUIDs in 16 bytes, some in a 36-character string, some with reordered byte groups (SQL Server). Round-trips between systems can rearrange bytes silently.
• UUIDs are unique, not unguessable. v1 and v7 both expose timestamps; even v4 is not a secret. Do not use a UUID as an authentication token.

Frequently asked

Should I use v4 or v7?

Use v7 for anything that becomes a database primary key or is sorted by creation time. Use v4 when ordering would leak information you don't want exposed, such as an account number assigned in sequence.

Are UUIDs really unique?

For practical purposes, yes. v4's 122 random bits give a collision space of 2¹²²; you would need to generate billions per second for centuries before encountering one. v7's random portion is smaller per millisecond but still collision-resistant across systems.

What does the version digit mean?

The 13th hex digit of a UUID identifies how it was generated — v1 timestamp+MAC, v4 random, v7 time-ordered random, and so on. The variant bits in the next group identify the layout.

Can I migrate existing v4 IDs to v7?

Not directly — v4 has no embedded timestamp to recover. New rows can adopt v7 going forward, and the database can still index v4 and v7 together as 16-byte values. The migration is conceptual, not a rewrite.