Skip to content

Free · Generators & Security · runs in your browser

UUID Generator & Validator

By Nayeem, Software Developer of fastsavemedia.comLast reviewed

UUID Internals — How It Works

Structure of a UUID

A UUID is 128 bits, conventionally formatted as xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx where M identifies the version (1–8) and the top bits of N identify the variant (RFC 9562 uses binary 10).

time_low · 32 bits time_mid · 16 bits version + time_hi · 16 bits variant + clock_seq · 16 bits node / random · 48 bits

UUID v1

60-bit 100-ns timestamp since 1582-10-15 + 14-bit clock sequence + 48-bit node ID (often MAC). Leaks host and time.

UUID v3

MD5 of (namespace UUID || name). Deterministic — same inputs always give the same UUID.

UUID v4

122 bits of cryptographic randomness. Fully unordered. The default opaque identifier.

UUID v5

SHA-1 of (namespace UUID || name). Same deterministic behaviour as v3 but stronger hash.

UUID v6

Reorders v1 so the timestamp is in big-endian order, making the UUID sortable.

UUID v7

48-bit Unix ms timestamp + 74 bits random. Time-ordered, RFC 9562 native, ideal for primary keys.

UUID v8

122 bits of user-defined data. Use when you need a custom layout that still claims a UUID slot.

Best practices

  • Use v7 for primary keys — chronological order avoids index page splits.
  • Use v4 for public IDs — no information leakage.
  • Store as native UUID / BINARY(16), never as VARCHAR(36).
  • Always use a cryptographically secure RNG (crypto.getRandomValues, SecureRandom).
  • Pair UUIDs with a monotonically increasing sequence only if you need strict ordering.

Common mistakes

  • Using UUID v1 in public APIs — it leaks the host MAC address.
  • Storing UUIDs as VARCHAR(36) instead of uuid / BINARY(16) — 2.25× the storage.
  • Picking UUID v4 as a clustered primary key — destroys B-tree locality.
  • Generating UUIDs with Math.random() — not cryptographically secure.
  • Exposing v1 / v6 / v7 IDs externally without considering the embedded timestamp.

Key takeaways

  • UUID v7 is the modern default for database primary keys (RFC 9562, ).
  • UUID v4 remains correct for opaque external identifiers.
  • ULID and v7 are functionally equivalent in ordering guarantees; choose ULID for shorter string form, v7 for native DB UUID type.
  • Snowflake wins on raw size (64-bit) but requires worker-id coordination.
  • NanoID and CUID2 are for URLs and anti-enumeration, not for high-throughput databases.
  • Collision probability for UUID v4 reaches 50% around 2.71 × 10¹⁸ generated IDs — effectively never in practice.

Frequently asked questions

What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit identifier standardised by RFC 9562 that can be generated independently across systems with a negligible probability of collision.

Which UUID version should I use for a database primary key?

Use UUID v7. It embeds a Unix millisecond timestamp in the leading bits, so it is monotonically increasing and dramatically improves B-tree index locality compared to UUID v4.

What is the difference between UUID v4 and UUID v7?

UUID v4 is fully random and unordered, ideal for opaque public IDs. UUID v7 is time-ordered: the first 48 bits are a Unix ms timestamp, so v7 values sort chronologically and index efficiently in databases.

What is ULID?

ULID is a 128-bit identifier with a 48-bit timestamp and 80 bits of randomness, encoded in Crockford Base32 as a 26-character string. It is lexicographically sortable and URL-safe.

How many UUIDs can be generated before a collision?

For random UUID v4 you would need to generate roughly 2.71 quintillion (2.71 × 10^18) UUIDs to reach a 50% collision probability, making accidental collisions effectively impossible.

Is the tool free?

Yes. UUID Studio runs entirely in your browser, requires no signup and is 100% free.