UUID Generator

Generate UUIDs that will not collide

A UUID (universally unique identifier), also called a GUID, is a 128-bit value written as 32 hexadecimal digits in the familiar 8-4-4-4-12 pattern. This generator produces RFC 4122 version-4 UUIDs — the kind you reach for when you need a primary key, a request id, or a token that is safe to create independently on many machines without coordination.

122 random bits, formatted

A version-4 UUID is 122 random bits plus a few fixed bits. The generator fills 16 random bytes from the Web Crypto API, then sets the version nibble to 4 and the variant bits to 10xx exactly as the standard requires, and finally formats the bytes as lowercase hexadecimal with hyphens in the canonical positions. Where the browser exposes crypto.randomUUID, that native call is used directly. Either path draws from a cryptographically secure source, so the result is unpredictable and the chance of two generated UUIDs ever matching is vanishingly small.

The format options are pure presentation applied after generation: changing case, stripping hyphens, or wrapping the value in curly braces does not change the underlying random bytes.

Reading a v4 UUID

A canonical UUID looks like f47ac10b-58cc-4372-a567-0e02b2c3d479. The structure is:

• First three groups (f47ac10b-58cc-4372): 60 random bits.
• Version nibble: the 4 at the start of the third group. This marks it as version 4.
• Variant bits: the first character of the fourth group is 8, 9, a, or b (the 10xx variant), marking it as an RFC 4122 UUID.
• Last two groups (a567-0e02b2c3d479): more random bits.

Together, 122 bits of randomness. The probability that two independently generated v4 UUIDs collide is astronomically low — roughly 1 in 10^36 for a single pair.

Format options explained

Common uses for v4 UUIDs

Database primary keys. In PostgreSQL, the uuid column type stores v4 UUIDs efficiently. In MySQL and SQL Server, the CHAR(36) or UNIQUEIDENTIFIER types are common. Unlike integer sequences, UUID primary keys do not expose record-count information and are safe to generate on the client before the database row exists.

Request and correlation IDs. Distributed systems often assign each request a UUID at the entry point and propagate it through every downstream service. This makes log correlation straightforward: searching for a UUID shows the complete request path.

Session tokens and idempotency keys. A v4 UUID is unpredictable enough to use as a session token or an API idempotency key. Because generation is cryptographically random and local, these IDs are safe to use directly as short-lived secrets.

Seeding test fixtures. When writing integration tests, generating 50 or 100 UUIDs in one click lets you fill a seed file or a test-data factory without inventing fake IDs manually.

The standard, updated: RFC 9562 and the new v7

UUIDs are standardised in RFC 9562, which in 2024 replaced the original RFC 4122 and added new versions. The one worth knowing alongside v4 is UUIDv7: it embeds a millisecond Unix timestamp in the high bits followed by random bits, so v7 values generated over time are roughly sortable by creation moment. That matters for databases: purely random v4 primary keys scatter inserts across a B-tree index, causing page splits and cache misses at scale, while v7 keys cluster new rows together like an auto-increment does — without sacrificing distributed, coordination-free generation. Rule of thumb: v4 for opaque identifiers, tokens and cases where creation time must not leak; v7 for high-volume database keys.

How impossible is a collision, numerically

A v4 UUID carries 122 random bits, so there are about 5.3 × 10³⁶ possible values. By the birthday approximation, you would need to generate roughly 2⁶¹ ≈ 2.3 quintillion UUIDs to reach even a 50% chance of a single collision — generating a billion per second, that is over 70 years. The honest caveat is that this guarantee rests entirely on the quality of the randomness: UUIDs made with a weak or seeded PRNG can and do collide in the wild. This tool uses the browser’s cryptographically strong crypto.getRandomValues (the same source behind the native crypto.randomUUID() API), so the mathematical guarantee applies.

Formatting note: RFC 9562 specifies lowercase hex output (while requiring parsers to accept uppercase), so lowercase is the interoperable choice this tool defaults to — normalise case before comparing UUIDs as strings, or compare the parsed bytes instead.