UUID generator

Where UUIDs are used

A UUID (universally unique identifier, also called GUID on Windows) is a 128-bit value written as 32 hex digits in five groups: 8-4-4-4-12, for example 3f1c2b7e-9a4d-4c1e-8b2f-6d0e5a7c9b13. The point is that any system can create one on its own, without asking a central counter, and still be confident it will never clash with an ID created somewhere else.

That property is handy in many places:

• Primary keys in databases, especially when records are created on several servers or offline on client devices and synced later.
• Request and correlation IDs that follow one operation through logs of many services.
• File names for uploads, so two users uploading photo.jpg never overwrite each other.
• Idempotency keys for payment and order APIs.
• Test fixtures and seed data that need realistic IDs.

Version 4 and version 7

The tool offers the two versions that matter for new work today. Both have the same format and length; the difference is what the bits contain.

UUID v4 (random)

Apart from 6 fixed bits that mark the version and variant, all 122 bits are random. You can recognise a v4 by the 4 at the start of the third group. These come from the browser's crypto.randomUUID(), which draws on the operating system's cryptographically secure random source.

Use v4 when the ID must reveal nothing: invitation tokens in URLs, public resource IDs, anything where knowing one ID should not help guess another or tell when it was made.

UUID v7 (time-ordered)

Standardised in RFC 9562 in 2024, v7 puts a 48-bit Unix timestamp in milliseconds at the front and fills the remaining 74 bits with random data. The third group starts with 7. Because the timestamp comes first, v7 values sort in creation order as plain strings or bytes.

That matters for databases. B-tree indexes store keys in order, and random v4 keys land on random pages, causing page splits and poor cache use as tables grow into millions of rows. Time-ordered keys are appended near the end of the index, much like an auto-increment integer, while keeping the "generate anywhere" property. For new tables in PostgreSQL, MySQL or SQL Server, v7 is usually the better primary key.

Two caveats: the timestamp is readable, so a v7 discloses when the record was created, to the millisecond. And this generator does not add a sub-millisecond counter, so IDs produced within the same millisecond, as happens inside a single batch, are ordered among themselves by their random part rather than by generation order.

How unlikely is a duplicate

With 122 random bits there are about 5.3 × 10^36 possible v4 values. By the birthday bound, you would need to generate around 2.7 × 10^18 of them to reach a 50% chance of a single collision. At a billion per second, that takes over 80 years.

For v7 the random part is 74 bits, but it only has to be unique among IDs created in the same millisecond. Even at a million IDs per millisecond the chance of a clash stays negligible.

In practice, duplicates come from bugs, not maths: a hard-coded example ID copied into production, a seeded or non-cryptographic random generator, or a cloned virtual machine replaying state. Generating in the browser with the system's secure randomness avoids the last two.

Format details and storage

• Case. RFC 9562 says UUIDs are written in lowercase and compared case-insensitively. The Uppercase option exists for systems and documentation that use the Windows GUID style.
• Braces and hyphens. Some Microsoft tools show GUIDs in {curly braces}. Strip them, or the hyphens, only if the target system expects that form.
• Storage. Store UUIDs in a native type (uuid in PostgreSQL, BINARY(16) in MySQL) rather than CHAR(36). The binary form takes 16 bytes instead of 36 and compares faster.
• Batch size. Up to 500 at a time, one per line, ready to paste into a SQL script or spreadsheet. Clicking Generate new replaces the whole list.

UUIDs are identifiers, not secrets. A v4 is hard to guess, but if it grants access to something, treat that as a convenience link, not authentication. For credentials use the password generator. To decode the creation time of a v7, take its first 12 hex digits, convert them to decimal and paste the number into the timestamp converter.