UUID Generator

Generate cryptographically random v4 UUIDs, one at a time or in bulk.

About v4 UUIDs

  • Each UUID is 128 bits, 122 random, 6 reserved for version and variant.
  • Collisions are mathematically possible but practically vanishing, you'd need to generate billions per second for decades to realistically hit one.
  • Generated here via crypto.getRandomValues, cryptographically strong randomness.

Frequently asked questions

What kind of UUIDs are generated?

Version 4 UUIDs, which are 128 bits of mostly random data. Six bits are reserved to mark the version and variant; the other 122 are random.

Are these UUIDs unique enough for production?

Yes. The collision probability is so small that generating 1 billion UUIDs per second for 85 years would produce only a 50% chance of one duplicate.

Is the randomness cryptographically secure?

Yes. We use crypto.getRandomValues rather than Math.random(), so the output is suitable for security-sensitive identifiers.

Can I generate UUID v1 or v7?

Not currently. The tool focuses on v4 because it is the most common choice for distributed IDs. Time-based UUIDs are on our roadmap.

Why 122 random bits make coordination unnecessary

A version 4 UUID contains 122 bits of randomness (6 of the 128 are version and variant markers). The space is so large that the birthday-paradox math says you would need to generate about 2.7 x 10^18 UUIDs to reach a 50% chance of a single collision anywhere. Generating a billion per second, that takes roughly 86 years. This is the entire value proposition: any machine, offline, with no central registry, can mint an identifier that is unique across every system on Earth for all practical purposes.

The versions you will actually encounter

  • v4 (random) is the default choice and what this tool generates.
  • v1 embeds a timestamp and historically the MAC address... sortable, but it leaks when and where it was made.
  • v5 is deterministic: the same namespace plus name always hashes to the same UUID, useful for stable IDs derived from external keys.
  • v7 (standardised in 2024) leads with a Unix timestamp followed by randomness: time-ordered like v1, private like v4, and increasingly the recommended choice for database primary keys.

Database reality check

Random v4 keys insert at random positions in a B-tree index, causing page splits and cache misses at scale; that is the engineering case for v7's time-ordered layout. Also remember UUIDs are unique, not secret: they are safe to expose in URLs as identifiers, but possession of an ID must never be the only thing standing between a user and the resource it names.

Format details worth recognising

  • The canonical form is 36 characters: 32 hex digits in 8-4-4-4-12 grouping. Storage formats vary... some systems strip hyphens, some store raw 16 bytes.
  • The version digit is the first character of the third group: xxxxxxxx-xxxx-4xxx-... marks a v4.
  • Case is insignificant; the RFC recommends lowercase output, and comparing UUIDs case-insensitively avoids a classic integration bug.
  • The nil UUID (all zeros) is a legitimate reserved value some systems use as "no ID"... treat it as null, never as a real identifier.
  • UUIDs in URLs are fine; UUIDs as security tokens are not. Unique is not the same as unguessable-with-authorisation.

Advertisement