UUID Generator

A UUID (Universally Unique IDentifier sometimes called GUID in the Microsoft ecosystem) is a 128-bit value formatted as 32 hexadecimal digits in the canonical 8-4-4-4-12 layout. The point of a UUID is that anyone can generate one anywhere without coordination and the probability of two independently generated UUIDs colliding is so low it can be treated as zero in any practical system. The original UUID specification (RFC 4122 published in 2005) defined five versions — v1 (timestamp + MAC address) v2 (DCE Security basically unused) v3 (MD5 hash of namespace + name) v4 (random) and v5 (SHA-1 hash of namespace + name). For two decades v4 was the de facto standard for application IDs because the alternatives leaked information (v1 leaked your network MAC address; v3/v5 leaked the input being hashed). In May 2024 the IETF replaced RFC 4122 with RFC 9562 which added three new versions and two sentinels: v6 is a reordered v1 so the same timestamp+node layout sorts chronologically; v7 prefixes 48 bits of unix_ts_ms before 74 bits of randomness — the version most new code should reach for; v8 reserves a custom layout for application-defined contents. Two new constants joined as well: Nil (all zeros a placeholder for no UUID yet ) and Max (all ones a sentinel for range-query upper bounds). This generator emits every one of those nine variants — v1 through v8 plus Nil and Max — so you never have to fall back to a separate tool for a non-v4 case.

Where v4 and v7 produce randomness v3 and v5 produce a deterministic UUID by hashing a namespace UUID together with a name string. Same namespace + same name always produces the same UUID anywhere forever. RFC 4122 defines four standard namespaces — DNS (Record URL (6ba7b811-...) OID (6ba7b812-...) and X.500 (6ba7b814-...) — but you can use any UUID as a namespace and the spec recommends doing so to scope your IDs to your application. The difference between v3 and v5 is the hash function: v3 uses MD5 v5 uses SHA-1. Both are 128-bit hashes both are truncated to 122 bits + version + variant bits and both predate the modern collision-resistance bar. For new code use v5 unless you must interop with an existing v3 implementation — SHA-1 is more collision-resistant in practice and Web Crypto exposes it natively in every browser. Common uses include content-addressable storage keys idempotency keys for webhook deliveries and stable IDs for entities that have a natural unique key (URLs email addresses file paths).

Random UUIDs (v4) and database B-tree indexes are a known antipattern. Every insert lands at a random position in the index which means new rows are constantly being merged into pages spread across the disk causing page splits fragmentation and aggressive cache invalidation. For tables with millions of rows the overhead can be staggering — Heap and others have published benchmarks showing v4 inserts running 5-10x slower than auto-increment integers with index size 2-3x larger. The classic mitigation was to use a sequential ID column for the primary key and treat the UUID as a separate external_id column which works but forces every external API call to do a lookup-by-uuid that the database must internally translate to the underlying numeric ID. UUIDv7 fixes the root cause. Because the high 48 bits are a millisecond timestamp every UUIDv7 generated within the same minute clusters into the same B-tree page region and inserts append to the rightmost edge of the index — the exact pattern auto-increment integers use. Your application keeps the unguessable distributed-system-friendly UUID semantics and your database keeps the index hygiene of a sequential ID. PostgreSQL added native UUIDv7 generation in version 18; MySQL exposes it via UUID_TO_BIN with the swap-flag set; SQLite MongoDB MariaDB and SQL Server all have user-space helpers or extensions. If you are starting a new project in 2026 and reaching for v4 out of habit switch to v7.

Yes. The randomness in every UUID emitted here comes from the platform's CSPRNG — the same cryptographically secure source used for HTTPS session keys session cookies and API tokens. In Node.js this is the OpenSSL RAND_bytes call; in browsers it is the OS-level entropy pool exposed via crypto.getRandomValues which on Linux means /dev/urandom on Windows means BCryptGenRandom and on macOS means Apple's CryptKit. There is no Math.random() in the path no time-based seed and no implementation that an adversary could predict or replay even with full knowledge of the system's state immediately before generation. Collision probability for a single UUIDv4 is governed by the birthday paradox over 122 bits of randomness — the rule of thumb is that you would need to generate roughly 2^61 UUIDs (about 2.3 quintillion) before a 50% chance of one collision among the entire batch. UUIDv7 reduces this to 74 bits of randomness within any one millisecond but you would still need to generate around 134 million UUIDs in the same millisecond from the same process to hit a 50% collision probability — which is far above what any single-process generator can produce. For all realistic workloads both versions are effectively collision-free.

For new database primary keys: UUIDv7. For random opaque tokens (password resets public file handles): UUIDv4. For deterministic IDs derived from a string (cache keys content-addressable IDs): UUIDv5. For legacy systems that already use v1 (some Cassandra deployments ZooKeeper COM): UUIDv6 — same timestamp+node layout but reordered to sort chronologically. UUIDv3 only if you must interop with a legacy MD5-based system; v5 supersedes it for all new code. UUIDv8 is for application-defined layouts when you need to encode something non-trivial into the UUID itself (shard ID tenant ID etc.).

UUIDv7 by a wide margin. Random UUIDs (v4) thrash B-tree indexes — every insert lands at a random offset causing page splits fragmentation and aggressive cache invalidation. Heap and PlanetScale benchmarks show v4 inserts running 5-10x slower than auto-increment integers on tables with millions of rows with index size 2-3x larger. UUIDv7 fixes this: its 48-bit timestamp prefix means inserts append to the rightmost edge of the index exactly the access pattern auto-increment integers use. PostgreSQL 18 has native uuidv7(); MySQL 8 has UUID_TO_BIN with the swap flag; SQLite MongoDB MariaDB and SQL Server all have user-space helpers.

v3 (MD5) and v5 (SHA-1) hash a namespace UUID together with a name string to produce a deterministic UUID. Same namespace + same name always produces the same UUID across processes and across machines. This is useful for content-addressable systems: hashing a URL with the URL namespace gives every cache instance the same key without coordination. RFC 4122 defines four standard namespaces — DNS (6ba7b810-...) URL OID and X.500. You can also use any UUID as a namespace. Use v5 over v3 unless interop with an existing MD5-based system forces your hand; SHA-1 has more collision resistance and Web Crypto exposes it natively.

Yes. UUIDv7 is defined by RFC 9562 ( Universally Unique IDentifiers (UUIDs) ) published May 2024 as the successor to RFC 4122. The new RFC also defines UUIDv6 (reordered v1 sorts chronologically) and UUIDv8 (custom layout). RFC 9562 retains v1 v3 v4 and v5 unchanged from RFC 4122 and adds the new Nil (all-zero) and Max (all-one) special UUIDs. PostgreSQL MySQL MongoDB MariaDB and SQL Server have native UUIDv7 support as of 2025.

UUIDv8 is the spec's escape hatch — RFC 9562 reserves the version 8 layout for custom application-defined contents. The version (1000) and variant (10) bits are still fixed in their canonical positions but the remaining 122 bits are yours to fill with whatever encoding makes sense: shard ID + timestamp + counter tenant ID + monotonic sequence geographic region + bucket index. Use it sparingly — most teams that reach for v8 actually want v7 plus an extra column which is simpler to query and migrate.

Nil (00000000-0000-0000-0000-000000000000) and Max (ffffffff-ffff-ffff-ffff-ffffffffffff) are special sentinel UUIDs defined by the spec. Nil predates RFC 4122 and is used as a placeholder for no UUID yet — many APIs accept it as input meaning server please generate one. Max was added in RFC 9562 specifically as a sentinel for range queries: SELECT * WHERE id < MAX_UUID matches every valid UUID which is useful for index-based pagination. Neither has any randomness or hashing — they are constants.

Yes in theory no in practice. Within a single millisecond two v7 UUIDs share the 48-bit timestamp prefix and only the remaining 74 bits of randomness differentiate them. Collision probability inside one millisecond is roughly 1 in 2^74 — about a hundred trillion times less likely than guessing a v4. If you generate millions of UUIDs in a single millisecond from one process some implementations include a monotonic counter in rand_a to guarantee strict ordering; this generator uses pure randomness in rand_a which is the simplest spec-compliant variant.

All bytes are pulled from the platform's CSPRNG via the Web Crypto API's crypto.getRandomValues. In Node 19+ this maps to OpenSSL; in browsers it maps to whichever entropy source the OS exposes (RDRAND on Intel /dev/urandom on Linux BCryptGenRandom on Windows). The same source is used by HTTPS for session keys so the entropy quality is appropriate for security-sensitive identifiers. For v3/v5 the randomness is moot — the output is fully determined by namespace + name. UUIDs never leave your browser; everything is computed client-side.

No. RFC 4122 and 9562 both define UUIDs as lowercase hex (0-9 a-f) with hyphens at fixed positions but the standards explicitly state that uppercase variants must be parsed as equivalent. Most databases store UUIDs as 16 raw bytes regardless of input case then format them lowercase on output. PostgreSQL MySQL SQLite MongoDB.NET Guids and Java UUIDs all round-trip to lowercase. This generator emits lowercase to match the canonical form.