UUID Generator — v4 and v7, with a UUID Decoder

A version 4 UUID is 128 bits, of which 122 are random. Six bits are fixed: four identify the version and two identify the variant, which is why the thirteenth hex digit is always 4 and the seventeenth is always 8, 9, a or b.

The random bits come from your browser’s cryptographic generator — crypto.randomUUID where available, and crypto.getRandomValues otherwise. Neither is Math.random, which is seeded predictably and must never be used for identifiers that end up in a database or a URL.

With 122 random bits, collisions are not a practical concern: you would need to generate billions of UUIDs before the probability became worth thinking about. The real trade-off is not uniqueness but ordering — random values arrive in no particular sequence, which scatters writes across a B-tree index. Where insert order matters, UUIDv7 or a ULID keeps the uniqueness and adds a time prefix.

Version 7, defined by RFC 9562 in 2024, fixes that ordering. Its first 48 bits are the Unix time in milliseconds, so values sort by creation time as plain strings and new keys land at the end of an index; the remaining 74 bits after the version and variant are random. Within a single millisecond this generator takes the previous value and adds one to those random bits, which is the RFC’s monotonic method, so a batch keeps the order it was made in, and if the bits would overflow it refuses rather than wrapping round. The cost is that a v7 UUID reveals when it was created, to the millisecond. Paste any UUID into the inspector to see that: v7 gives its time directly, v1 and v6 count hundred-nanosecond steps from October 1582 — and can carry the generating machine’s MAC address — while v4 carries no time at all.