UUID Generator

v4 or v7 — The Real Deciding Factor in Practice

The only difference between the two versions is whether they can be sorted. A v4 UUID is entirely random across 122 bits, so its creation order cannot be known. A v7 UUID, however, uses its first 48 bits for a millisecond timestamp, which means sorting it lexicographically is the same as sorting it by creation time. If you generate several v7 UUIDs in the result window, you'll see their beginnings are nearly identical and the values increase towards the end.

This difference matters because most UUIDs end up as database primary keys.

Using UUIDs as Primary Keys: The Deal with Index Fragmentation

MySQL's InnoDB engine physically sorts and stores data in primary key order (a clustered index). When you insert v4 UUIDs into this, each new row gets wedged into a random location in the index. This forces constant page splits, where a full page of data is split to make room. The result is a growing number of half-empty pages, meaning the same amount of data takes up more disk space and buffer pool memory. As soon as your data grows larger than the buffer pool, insertion performance will noticeably degrade.

Because v7 values increase chronologically, they are always appended to the right-hand end of the index. This creates an insertion pattern similar to an `AUTO_INCREMENT` key, with almost no page splits. This is why v7 is becoming the default choice for any new table that needs a UUID primary key.

• Storage Type: For MySQL, `BINARY(16)` uses less than half the space of `CHAR(36)`. The trade-off is that it's harder to inspect visually, so this requires team consensus. The "Remove Dashes" option is for columns using `CHAR(32)`.
• Secondary Indexes: In InnoDB, every secondary index also stores a copy of the primary key value. With a 36-byte primary key and five secondary indexes, that overhead is multiplied by five.
• PostgreSQL uses heap storage, so the impact isn't as dramatic as with InnoDB. However, v7 is still better for index insertion locality.
• If you're already running a system on v4, don't rush to change it. If your dataset is small enough to fit comfortably in the buffer pool, you won't feel a difference.

The Cost of v7: Creation Time Is Exposed in the Value

The first part of a v7 UUID is a raw millisecond timestamp. Without any special tools, anyone can read when that account or order was created. Exposing a v7 UUID in a public URL tells the world the exact creation time of that resource.

If you're running a service where competitors could deduce your user growth rate, or where a user's sign-up time is sensitive information, a safer architecture is to use v7 for the internal primary key and a separate v4 UUID as the externally exposed identifier.

Why Have Formatting Options?

The three checkboxes only change the appearance, not the underlying value. You can toggle them on and off without regenerating. However, the system you're pasting into often dictates which format you need.

• Remove Dashes: Use this for `CHAR(32)` columns, short URL paths, or filename prefixes. This produces a 32-character hex string.
• Brace Notation: This is a convention for GUIDs in the Windows and .NET ecosystem. The Windows Registry or COM-related settings often require this `{…}` format.
• Uppercase: This is another format frequently seen in .NET and Windows documentation. The standard specifies lowercase generation and case-insensitive comparison, but storing them consistently in one case in your database is a good practice to prevent accidents.

Will They Really Never Collide? Can You Trust This Value?

A v4 UUID has 122 random bits. To put that in perspective, if you generated one billion UUIDs every second for 100 years, the probability of a single collision is still negligible. In practice, you can safely design your systems assuming they are unique.

However, that premise depends on a proper random number generator. This tool uses the browser's `crypto.getRandomValues`, so its output is cryptographically secure. Some older languages and libraries had implementations that used weak seeds like the time or process ID. Such values can be predicted, which invalidates the uniqueness guarantee of a UUID.

For v7, ordering within the same millisecond is a real concern. This tool addresses it by incrementing the random portion of the UUID (per RFC 9562's "monotonic random" section) when generating multiple values in the same millisecond. This guarantees their creation order. It's why generating 500 at once maintains a perfect top-to-bottom sort. If you were to implement this yourself and omit this logic, values created in the same millisecond would be out of order.