Developer UUID generator
Generate RFC-compliant UUIDs in bulk, either random v4 or time-sortable v7, with formatting options and no server involvement.
Generated with your device’s own secure randomness
Your files stay on your device. The tool works directly in your browser, using your device to process your files. Nothing is sent to our servers, and we never receive, store, or see your files or figures.
Share result
Cite
Cite this page
Reembun. (2026, July 27). UUID generator. https://reembun.com/uuid-generator
How to use it
Pick a version
v4 random suits almost everything. v7 is time ordered, so ids generated later sort later, which is kinder to a database index.
Set how many
Generate one, or a batch when you are seeding fixtures or a migration.
Format them
Hyphens, uppercase and braces cover the shapes different systems expect, such as the registry format on Windows.
Copy the list
Copy all takes the batch at once. Every value comes from your browser's cryptographic random source.
What a UUID is
A UUID is a 128-bit identifier written as 32 hexadecimal digits in five hyphenated groups:
550e8400-e29b-41d4-a716-446655440000
^ ^
version variantThe first digit of the third group gives the version. The first digit of the fourth group encodes the variant. The point of the format is that it can be generated independently, on any machine, with no coordination, and still be unique.
Version 4: random
122 of the 128 bits are random; the remaining 6 are fixed version and variant markers. This tool draws them from your browser’s own cryptographically secure randomness, the same source used for encryption keys.
v4 is the right default for anything that is not a primary key: correlation IDs, idempotency keys, file names, session identifiers.
Version 7: time-ordered
Standardised in RFC 9562 (May 2024), v7 puts a 48-bit Unix millisecond timestamp in the leading bits and fills the rest with randomness.
0192f8e2-7c34-7a91-b3d5-8f2e1c7a9b04
└──────────────┘
timestamp (ms)Because the timestamp comes first, sorting v7 UUIDs as plain strings sorts them chronologically. That single property is why they behave so much better as database keys.
Why key ordering matters
Databases store primary keys in a B-tree. Inserting sequential values appends to the rightmost page, which is cheap, cache-friendly and compact. Inserting random values writes to arbitrary pages, forcing splits and evicting cache.
The practical effect on a large table:
| Random v4 | Sequential v7 | |
|---|---|---|
| Insert location | Anywhere in the index | Always at the end |
| Page splits | Frequent | Rare |
| Buffer cache hit rate | Poor at scale | High |
| Index fragmentation | Significant | Minimal |
Benchmarks on MySQL InnoDB have shown random UUID keys degrading insert throughput by an order of magnitude on tables large enough to exceed the buffer pool. v7 largely closes that gap while keeping the properties that made UUIDs attractive in the first place.
Storage
Do not store UUIDs as 36-character strings if you can avoid it. PostgreSQL has a native uuid type occupying 16 bytes; MySQL can use BINARY(16). Against VARCHAR(36) that more than halves the storage and shrinks every index that touches it.
The other versions
- v1: timestamp plus MAC address. Leaks the generating machine’s hardware address; superseded by v7.
- v3 / v5: deterministic, derived from hashing a name within a namespace (MD5 and SHA-1 respectively). Useful when the same input must always produce the same UUID.
- v6: a reordering of v1 for sortability. Exists mainly as a migration path; new systems should use v7.
- Nil: all zeroes,
00000000-0000-0000-0000-000000000000. A defined placeholder for “no UUID”.
Common questions
Can two UUIDs collide?
In principle yes, in practice no. A v4 UUID has 122 random bits. To reach a 50% chance of a single collision you would need to generate about 2.7 × 10¹⁸ of them. At a million per second that takes roughly 86,000 years. You will hit hardware failure, cosmic-ray bit flips and the heat death of your budget long before a collision.
Should I use v4 or v7 for a database key?
v7, in almost every case. Random v4 keys scatter inserts across the whole B-tree index, causing page splits and poor cache locality, a well-documented cause of write slowdown in MySQL and PostgreSQL at scale. v7 is time-ordered, so new rows append at the end of the index like an auto-increment integer while keeping global uniqueness.
Does v7 leak information?
It embeds a millisecond timestamp, so anyone holding a v7 UUID can tell when the record was created, and can order two records in time. That is usually harmless and sometimes useful, but it is a real disclosure. If creation time is sensitive, use v4.
Is a GUID the same as a UUID?
Yes. GUID is Microsoft's name for the same 128-bit identifier. The only difference you will meet in practice is formatting: Microsoft tooling often wraps them in braces and uses uppercase.
Last reviewed
