UUID Generator
Generate RFC 4122 version 4 UUIDs — cryptographically random, batch up to 100.
- Free · no sign-up
- Instant results
- Privacy-friendly
Other Developer Tools
What you get
This generates version 4 UUIDs as defined by RFC 4122 — 128-bit identifiers where the bits are random apart from the handful reserved to mark the version and variant. You can produce up to 100 at a time and choose the output format: standard lowercase with hyphens, uppercase, or with the hyphens stripped for contexts that want a plain 32-character hex string.
The randomness comes from a cryptographically secure source, not from a general-purpose random function seeded by the clock. That distinction matters more than it sounds: identifiers generated from a weakly seeded generator can be predicted by someone who knows roughly when they were created, which turns a UUID in a URL into a guessable one.
Why collisions are not something you need to plan for
A v4 UUID carries 122 random bits, which is about 5.3 undecillion possible values. To reach a 50% chance of a single collision you would need to generate roughly 2.7 quintillion of them. Put concretely: producing a billion UUIDs every second for a century leaves the probability of one collision at well under one in a billion.
This is what makes UUIDs so useful in distributed systems. Any number of services can mint identifiers independently, with no coordination, no shared counter, and no round-trip to a central database, and still be safe from conflicts. It is also why you can assign an ID on the client before a record has ever reached the server.
The database trade-off worth knowing about
v4 UUIDs are random, which means consecutive inserts land in unrelated places in a B-tree index. On a table with a clustered primary key — the default for MySQL InnoDB — this causes page splits and index fragmentation that a sequential integer key would never produce. The effect is invisible on small tables and very noticeable on large, write-heavy ones.
There are three standard responses. Keep an auto-increment integer as the internal primary key and expose a UUID as a separate indexed column, which is the most common pattern. Store the UUID as 16 binary bytes rather than a 36-character string, which cuts index size by more than half. Or use a time-ordered identifier such as UUID v7 or ULID, which keeps global uniqueness while sorting roughly by creation time, giving you back the insert locality.
What a UUID does not give you
Unguessable is not the same as authorised. A v4 UUID in a URL is impractical to brute-force, and that genuinely helps — but it is still a bearer secret that leaks through browser history, Referer headers, server logs, and anything a user pastes into a chat. Resources behind a UUID still need a real permission check on every request.
They also carry no metadata. A v4 UUID tells you nothing about when it was created or where it came from, by design. If you need creation order, store a timestamp column or use v7.