A UUID (Universally Unique Identifier) is a 128-bit value, conventionally written as 32 hexadecimal characters in the pattern 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000

The 4 after the second dash and the a at the start of the fourth group are not arbitrary — they encode the version and the variant. The tool above generates UUIDs in your browser; nothing leaves your machine.

Versions in practice

There are several UUID versions defined by RFC 9562 (which superseded the older RFC 4122 in 2024). Three are common:

Version	Source of bits	Order	Use case
v1	Time + MAC address	Time-ordered	Legacy. Leaks the host MAC.
v4	Random (122 bits)	Unordered	Default for app-level IDs. The most common version.
v7	Unix-millisecond timestamp + random	Time-ordered	New default for database keys. Better B-tree locality than v4.

Versions 2, 3, 5, 6, and 8 exist but are rarely used outside specific systems.

Where the version digit lives

The character at position 13 (the first character of the third group) is the version. The character at position 17 (the first character of the fourth group) is the variant — for the standard variant it’s one of 8, 9, a, b. So:

550e8400-e29b-41d4-a716-446655440000
              ^    ^
              |    └── variant (a → standard variant)
              └─────── version (4 → version 4)

This makes UUID strings self-identifying: any decoder can read those two positions to know which version it’s dealing with.

v4 collision math

A v4 UUID has 122 bits of randomness (128 minus 4 for version, minus 2 for variant). The chance of generating the same UUID twice is negligible at any practical scale — generating a billion v4 UUIDs per second for a hundred years still leaves the collision probability at ~50% only after astronomically larger generation rates. For application use, treat v4 collisions as impossible without coordination.

The corollary: v4 is safe to generate independently on every host with no central coordinator. That’s why it’s the default for distributed systems.

Why v7 exists

v4’s randomness is also its weakness: when used as a primary key in a B-tree-indexed database, every insert lands in a random leaf. The index thrashes the cache and fragments. v7 solves this by putting a Unix-millisecond timestamp in the high bits:

v7 layout (128 bits):
  48 bits: Unix milliseconds
  4 bits:  version (= 7)
  12 bits: random (sub-millisecond ordering)
  2 bits:  variant
  62 bits: random

Sequentially-generated v7 UUIDs sort in time order. Inserts hit the right edge of the B-tree, the way auto-increment integers do, but without a central counter. Most databases that have started supporting native UUID-as-primary-key (PostgreSQL with uuidv7(), recent MySQL extensions) recommend v7 over v4.

The cost: v7 leaks the creation timestamp. If that’s a privacy concern (publicly-exposed IDs that should not reveal when an account was created), use v4.

v3 and v5: deterministic UUIDs

v3 (MD5) and v5 (SHA-1) are namespace-based: same namespace + same name → same UUID. Useful when you need a stable ID derived from a known string (a URL, a DNS name) without storing a mapping table.

uuidv5(namespace_url, "https://example.com/users/123")
  → always the same UUID for that input

v5 is preferred over v3 because SHA-1 is the better hash. (The “broken-for-cryptography” reputation of SHA-1 doesn’t matter here — UUIDs aren’t cryptographic; the hash is just a bit-derivation function.)

Common pitfalls

Storing UUIDs as strings in databases. A 36-char string is 36 bytes; the underlying 128 bits fit in 16. Most databases have a native UUID or BINARY(16) type that’s 2.25× smaller and faster to index. Use it.
Generating UUIDs by concatenating Math.random() calls. Browsers expose crypto.randomUUID() — use it. The tool above uses the browser’s crypto API, not Math.random().
Using UUIDs as session tokens. A v4 UUID has 122 bits of entropy, which is enough for cryptographic use, but the encoding is wasteful (36 ASCII chars for 16 bytes). Purpose-built tokens (a base64url-encoded 32-byte random value) are denser.
Treating UUIDs as opaque when they aren’t. v1 and v7 leak timestamps. v3/v5 leak that the input was hashed. If the ID is exposed publicly, pick the version with the privacy properties you actually want.

For other random-token needs, see the API key generator (URL-safe random tokens) and the password generator (human-typeable random strings).

UUID Generator