A UUID (Universally Unique Identifier) is a 128-bit value formatted as 32 hex digits in five groups, like 550e8400-e29b-41d4-a716-446655440000. The goal is always the same — an identifier so unlikely to collide with another that you don't need a central authority handing them out — but different UUID versions get there in different ways.
UUID v1: time and hardware based
Version 1 UUIDs are generated from the current timestamp plus the generating machine's MAC address (or a random node ID as a fallback). This makes them sortable roughly by creation time, which is occasionally useful, but it also leaks information — the MAC address component means a v1 UUID can reveal which machine generated it, which is a real privacy consideration if the UUID is exposed externally.
UUID v4: pure randomness
Version 4 UUIDs are generated from 122 random bits (6 bits are fixed to mark the version and variant). There's no timestamp, no MAC address, no sequential pattern — just cryptographically random data. The collision probability is astronomically low: you'd need to generate around a billion UUIDs per second for about 85 years before a 50% chance of a single collision.
This is why v4 became the default choice for almost everything: database primary keys, session identifiers, API request IDs, distributed system correlation IDs. It requires no coordination between generators, leaks no machine information, and the collision risk is a non-issue in practice.
When you'd still reach for v1 (or v7)
- You need IDs that sort roughly chronologically without a separate timestamp column — though newer UUID v7 (timestamp + random, standardized more recently) is now the better answer to this than v1
- You're integrating with a legacy system that specifically expects v1 format
- You want to debug which node/service generated an ID during a migration (accepting the privacy trade-off in an internal, non-exposed system)
Quick reference
- Need a unique ID with no other requirements → v4
- Need it to sort by creation time → v7 if your stack supports it, v1 if not
- Never expose v1 UUIDs generated on machines where the MAC address is sensitive
For the vast majority of use cases — primary keys, tracking IDs, temporary file names — v4 is the right default. Generate as many as you need, formatted and ready to paste into code or a database seed script.