UUID Generation
Universally unique identifiers, and what the version number means
A UUID (Universally Unique Identifier, standardized in RFC 4122 and its 2024 successor RFC 9562) is a 128-bit identifier designed to be unique across systems without any central coordination — no database, no registry, no server checking for collisions. That's the whole point: any two systems anywhere can each generate a UUID independently and, for all practical purposes, never produce the same one. UUIDs show up everywhere identifiers need to be assigned without a central authority — database primary keys, session tokens, distributed system record IDs, file and object identifiers.
The version number in a UUID (the "4" in UUID v4) describes how it was generated, and the versions matter differently depending on what you're using it for. Version 4 is the most common default — essentially 122 random bits (6 bits are fixed to mark the version and variant), and the collision probability is so astronomically low it's not a practical concern for any realistic system size. Version 1 encodes a timestamp and (originally) a network MAC address, which made it useful for ordering but also leaked identifying information, so it fell out of favor for public-facing use. Version 7, standardized more recently, encodes a timestamp in the most significant bits while keeping the rest random — combining v4's privacy with time-ordering, which turns out to matter a lot for database index performance, since random v4 keys fragment B-tree indexes in ways that sequential v7 keys don't.
UUID Forge generates v4 UUIDs by default with one tap, entirely offline, with Pro unlocking v1, v7, and nil-UUID generation plus batch generation and searchable history.
The app
Frequently asked questions
What's the difference between UUID v1, v4, and v7?
v1 encodes a timestamp and (historically) a network identifier, making UUIDs time-orderable but potentially leaking machine-identifying information. v4 is almost entirely random (122 random bits) — the most common general-purpose choice, with no ordering and no embedded information. v7, standardized more recently, embeds a timestamp in the leading bits while keeping the rest random, giving you both privacy (no embedded machine info) and time-ordering, which is particularly useful for database primary keys since it avoids the index-fragmentation problems that fully random v4 keys cause at scale.
How likely is a UUID collision?
For UUID v4, the random space is large enough (122 random bits) that even generating a billion UUIDs per second for about 85 years would give roughly a 50% chance of a single collision — in practical terms, it's not a realistic concern for virtually any application. This is why UUIDs can be generated independently across systems with no central coordination and still be treated as unique.
Are UUIDs safe to use as database primary keys?
Yes, functionally, but with a performance nuance: fully random UUIDs (v4) inserted as primary keys cause index fragmentation in many database engines, since new rows land in random positions throughout the index rather than appending at the end. Time-ordered UUIDs (v1 or the newer v7) largely avoid this because new values are naturally increasing, which is a major reason v7 was standardized — it gives you UUID's collision-resistance and decentralization with better index locality than v4.
What is the nil UUID?
The nil UUID is the special value `00000000-0000-0000-0000-000000000000` — all 128 bits set to zero. It's reserved by the spec to explicitly represent "no UUID" or an unset value, distinct from simply leaving a field empty, and is occasionally used as a sentinel value in systems that always expect a UUID-typed field to be populated.