UUID Generator

What it does

Generates version 4 (random), version 7 (time-ordered), or Nil UUIDs, one to a hundred at a time, in whichever surface format you need: canonical lowercase, uppercase, brace-wrapped, or the 32-character form with the hyphens stripped.

The second half of the page is an inspector. Paste any UUID and it reports the version, the variant bits, and the embedded timestamp where one exists. It reads v1 and v6 clock values, converts them from 100-nanosecond ticks since 1582-10-15 to an ISO instant, decodes the v7 millisecond field, and flags whether a v1 node field is a real MAC address or a randomised one.

How it works

Version 4 uses crypto.randomUUID, which is specified to draw from a cryptographically secure source. Version 7 is assembled here byte by byte because no browser API emits it yet: 48 bits of Date.now(), the four version bits, a 12-bit counter, two variant bits, and 62 bits from crypto.getRandomValues. Nothing is fetched from a server, so no value you generate is ever seen by anyone else.

Picking a version, and what v7 buys you

RFC 9562, published in May 2024, replaced RFC 4122 and added versions 6, 7, and 8. Version 7 is the one worth changing your defaults for.

The problem with v4 as a primary key is that it is uniformly random. Insert a million v4 keys into a B-tree index and every insert lands in a random leaf page, so the working set of the index is the whole index. Pages split, the cache hit rate collapses, and write amplification climbs. A v7 key is ordered by creation time, so inserts concentrate at the right-hand edge, pages fill and stay filled, and the recently written portion of the index is the only part that needs to be hot. On MySQL with InnoDB, where the primary key is also the physical row order, the effect is dramatic. On PostgreSQL it is smaller but real.

The counter is the subtle part. Millisecond resolution is coarse: a busy service can emit thousands of identifiers inside one tick, and if the remaining bits are purely random then ordering within that millisecond is arbitrary. RFC 9562 §6.2 describes using the 12-bit rand_a field as a monotonic counter, which is what this generator does. The first value in a millisecond seeds the counter in the lower half of its range, later values increment it, and a burst therefore sorts in creation order.

The cost is that a v7 UUID publishes its creation time to anyone holding it. Use the inspector on this page to see exactly how readable that is. For an identifier exposed to users, a password reset token, or anything where timing correlation matters, stay on v4 or use a separate opaque token. Neither version should be treated as unguessable simply because it is long: v4 has 122 random bits and is fine as a secret, but v7 has only 62.

The Nil UUID, all 128 bits zero, is defined in §5.9 as an explicit “no value” placeholder. It is a legitimate sentinel in a non-nullable column, and it is also what you get when a buggy client sends an uninitialised buffer, so seeing one in production data is worth a second look.

When to reach for it

• Seeding a database, fixture file, or test case with identifiers that will not collide.
• Deciding whether a UUID you found in a log is random or carries a timestamp you can correlate against.
• Checking whether an identifier from another system is a real RFC 9562 UUID or a lookalike with the wrong variant bits.
• Producing the brace-wrapped or uppercase form a Windows or .NET tool insists on.

Related tools

• Hash generator when you need a deterministic identifier derived from content rather than a random one.
• Timestamp converter to take the instant the inspector reports and move it into another timezone or format.
• JSON formatter for the payload the identifier arrived in.

Also nearby: the password generator when what you actually need is an unguessable secret rather than an identifier, and the Base64 encoder/decoder for systems that carry UUIDs in a shortened Base64url form.